3 qualités difficiles à trouver et qui font un(e) excellent(e) Propriétaire de Produit (Product Owner)

Les caractéristiques qui font un propriétaire de produit de qualité sont difficiles à lister, mais voici trois compétences ou attitudes auxquelles donner la priorité dans votre recherche.

3 Elusive Qualities of a Great Product Owner

https://www.agileconnection.com/article/3-elusive-qualities-great-product-owner par John Yorke

Quand il s’agit de diriger le développement d’un produit et de s’assurer de vous construisez ce dont l’utilisateur a réellement besoin, le/la propriétaire de produit est la personne la plus importante pour l’équipe. Il y a juste un problème : un bon product owner peut être vraiment difficile à trouver. Les caractéristiques qui font un bon propriétaire de produit sont insaisissables, mais voici trois qualités auxquelles vous devriez donner la priorité dans votre recherche.

Cela peut sembler excessivement simpliste, mais généralement les produits réussissent ou échouent en fonction de l’efficacité du propriétaire de produit dans l’équipe. Cela arrive principalement parce que nous sous-estimons l’importance (et la difficulté) des différents aspects du Product Ownership dans le processus de création de produit.

Le rôle d’un propriétaire de produit couvre tout le spectre, de la découverte à la livraison et plus et donc le choix de la bonne personne pour ce rôle est beaucoup plus important que le coach Agile ou autres membres d’équipe.

la propriétaire de produit comprend le métier et les taches des utilisateurs du futur produit.

Cependant, nous avons tendance à penser aux logiciels comme étant des objectifs principalement techniques. Notre focus est trop souvent placé sur la qualité et la capacité des ingénieurs, l’architecture et la conception et nous dépensons un temps disproportionné sur les processus, l’optimisation et l’efficacité. Nous avons tendance à oublier que l’échec le plus commun et le plus répété de tous les produits logiciels (peu importe leur qualité, optimisation et efficacité, ou combien les ingénieurs sont qui les ont construits sont doués) est que si vous construisez le mauvais article, ce sera un échec.

 

Un produit parfaitement conçu mais inutilisé n’est d’aucune valeur.

L’histoire est pleine de grands produits qui ont raté l’objectif. Combien d’applications avez-que vous téléchargées sur votre téléphone que vous avez arrêté d’utiliser après les trente premières secondes ? Sans mentionner les innombrables produits qui échouent à jamais d’atteindre les mains de clients et dont nous n’avons jamais entendu parler.

Les produits de l’informatique interne de l’entreprise sont souvent coupables d’une idée erronée: L’assomption semble être que comme les clients seront forcés d’utiliser le produit, nous ne devons pas vraiment leur demander ce qu’ils veulent ni comment ils l’utiliseront. Aussi, nous finissons souvent par construire de « bons » produits qui ne répondent pas au besoin réel de l’utilisateur.

CertYou est partenaire de DantotsuPM

Considérez cette citation de Peter Drucker : “Il n’y a sûrement rien d’aussi inutile que de faire avec une grande efficacité ce qui ne devrait pas être fait du tout.”

Quand on parle de direction du développement d’un produit et de garantir que vous construisez ce dont l’utilisateur a en réalité besoin, le propriétaire de produit est la personne la plus importante pour l’équipe. Trouver la bonne personne pour ce rôle est crucial au succès du produit.

Il y a juste un problème : un bon propriétaire de produit peut être vraiment difficile à trouver. Les caractéristiques qui font un bon propriétaire de produit sont insaisissables, mais voici cependant trois qualités auxquelles vous devriez donner la priorité dans votre recherche.

1. La capacité à différencier ce qui est nécessaire de ce qui est voulu

Une partie significative du rôle de propriétaire de produit est d’identifier ce qui est nécessaire pour résoudre les problèmes des utilisateurs, répondre à leurs besoins, leur permettre d’être meilleurs dans leur travail, ou maximiser leur amusement ou relaxation. Le rôle consiste avant tout en la compréhension du problème et la création d’une vision de comment ce problème pourrait être résolu. Pas la solution technique, mais le vrai besoin.

La raison pour laquelle cette compétence est si complexe est que les utilisateurs savent rarement de quoi ils ont besoin. Typiquement la vision d’un utilisateur est contrainte par ce qu’il fait actuellement. En conséquence, beaucoup de produits reviennent à retravailler un système papier existant ou une vieille approche.

Un faible propriétaire de produit donne aux clients ce qu’ils veulent ou ce qu’ils ont demandé mais un bon propriétaire de produit écoute et observe et peut mélanger veut et doit pour résoudre le problème du client et lui donner ce dont il a vraiment besoin.

Ce point nous mène à une citation intéressante par Henry Ford : “si j’avais demandé aux gens ce qu’ils voulaient, ils auraient répondu des chevaux plus rapides.”

Nous voyons souvent des arriérés de produits pleins d’histoires utilisateur qui sont vraiment juste des demandes client non filtrées. Il est plus facile de faire ce que le client demande que de trouver ce qui est en réalité nécessaire. Car cela exige typiquement de l’expérimentation, des retours utilisateurs, des conversations et de l’observation.

Cela peut aussi se produire quand les managers de département décident ce dont leur équipe a besoin ou veut sans impliquer les membres dans la discussion. Mais un bon propriétaire de produit passera du temps avec les utilisateurs du produit et verra comment ils l’utilisent. Un propriétaire de produit avec créativité, initiative et vision pour créer un grand produit vaut son pesant d’or.

2. La compréhension de ce qui exigée pour créer une application réussie

Peut-être à cause de l’accent placé sur le point numéro un, les sociétés choisissent souvent quelqu’un du côté business ou métier pour devenir le propriétaire de produit, car on voit leur connaissance du business comme primordiale et, dans des nombreux cas, la seule et unique qualification pour le rôle. Et pire encore, on leur demande souvent de tenir ce rôle en plus de leur travail habituel.

Cependant, les excellents propriétaires de produit comprennent quoi construire, mais sont aussi familiers avec le processus de développement. Ils comprennent les flux, les implications de la dette technique, l’automatisation et les tests. Ils comprennent aussi à quel point il est crucial de mettre le logiciel entre les mains d’utilisateurs aussitôt que possible.

En général, des propriétaires de produit « business » manquent souvent de cette connaissance et de cette expérience et ils suivront par erreur le désir d’un produit entièrement fonctionnel plutôt que d’apprécier la valeur de retours rapides. Beaucoup essaient d’inclure chaque fonction imaginable plutôt que de travailler vers un jeu de fonctions minimal pour obtenir des retours et tirer de la valeur le plus tôt possible.

Que préfèreriez-vous avoir ? Un propriétaire de produit expérimenté avec zéro connaissance business, ou un expert business avec zéro expérience de livraison de logiciel ? Avant que vous ne répondiez, considériez ceci : la connaissance business peut être obtenue par une discussion efficace, l’observation et les retours. Cependant, la compréhension d’un bon cycle de développement logiciel agile est beaucoup plus difficile à apprendre et il n’y a rien qui remplace l’expérience.

Typiquement les meilleurs produits résultent d’expériences, de tests et de retours, avec une volonté à être flexibles dans les réponses. Les propriétaires de produit posent des priorités et interprètent la vision, donc ils ont plus d’influence sur la création de produit que qui que ce soit d’autre. Leurs choix de priorités peut profondément impacter la valeur et la qualité du produit. S’ils manquent de compréhension sur l’importance des tests, des retours utilisateurs et des bons principes de développement logiciel, ils peuvent entrer en conflit et semer le désaccord dans une équipe.

Hexagon est partenaire de DantotsuPM

3. Une communication efficace avec les parties prenantes tant techniques que business

Pour terminer, il y a un énorme besoin de communication efficace. L’importance ne peut pas en être exagérée.

Les excellents propriétaires de produit écoutent, observent, explorent et réfléchissent. Ils demandent des retours, lisent entre les lignes et observent le langage corporel. Quand il s’agit de comprendre l’utilisateur, ils portent une grande attention aux détails et recherchent attentivement des points de douleur et de satisfaction. Ils cherchent les meilleures façons de servir leurs utilisateurs.

La plupart d’entre nous pensent à la communication comme à une conversation, mais pour un propriétaire de produit, l’observation et l’écoute sont aussi très importantes. Avoir de l’empathie avec l’utilisateur et le client est critique. Il est impératif de comprendre leur domaine et d’utiliser leur vocabulaire pour communiquer. Si vous ne comprenez pas certains termes, il est essentiel de développer une attitude attentive et de poser des questions pour montrer votre intérêt, votre envie d’apprendre et votre engagement.

Un grand propriétaire de produit apprend à dire non avec respect et d’une manière qui indique qu’il comprend ce qui est demandé. Grâce à cela, on ne devrait pas voir un bon propriétaire de produit comme un obstacle ou une barrière, mais un guide vers de bonnes décisions. Le mot « Non » devrait être délivré d’une façon qui laisse le client confiant que cette décision est juste, même si ce n’est pas ce qui a été initialement voulu et que le propriétaire de produit livrera le meilleur produit en fonction de tous les paramètres.

Au contraire, si le propriétaire de produit choisit de dire oui, il devrait être capable d’en transmettre les implications. Les propriétaires de produit devraient avoir un certain nombre d’outils qui peuvent aider les gens à comprendre leurs décisions.

Le propriétaire de produit doit aussi communiquer avec l’équipe de développement et doit comprendre des termes techniques de développement pour qu’ils puissent avoir une pleine compréhension de la mise en œuvre technique, même s’ils n’ont pas d’autorité sur comment les choses sont faites. Autrement dit, ils devraient avoir un fort intérêt dans la compréhension du processus.

Ils doivent aussi être capables de communiquer des besoins business et des termes métier d’une façon qui donne du sens à l’équipe de développement. Être respectés et compris tant par le business que l’équipe technique est un exploit majeur et comme nous le savons, tout groupe parle dans le jargon que seuls ses membres comprennent. Ces signes verbaux que l’on doit expliquer à un étranger peu familier peuvent démoraliser l’équipe. Il est important de ne pas sous-estimer cette capacité.

Les propriétaires de produit ont aussi besoin de créativité pour communiquer des idées de design, ou, si les idées viennent d’autres, la capacité de comprendre cette créativité et de la transmettre aux équipes business et techniques. Il en va de même pour les parties prenantes principales (mis à part les utilisateurs). Ce groupe finance généralement le produit et ils veulent voir la progression et un bon management de leur investissement, donc ils peuvent demander des prévisions et insister même sur des engagements fermes.

Et si un produit doit être vendu, il est probable que le propriétaire de produit devra être impliqué avec les ventes et le marketing, ce qui amène tout un train d’autres compétences et de problèmes de communication, y compris la compréhension des implications sur le marché.

En prenant tout ceci en considération, nous avons maintenant chargé notre propriétaire de produit du besoin de communiquer avec les gens expérimentés qui prennent des décisions financières, d’exprimer les risques et les prévisions de façon concise, mais significative et transparente, informative et confiante. Un propriétaire de produit devrait tenir bon sur sa position et parler vrai face aux autorités et au pouvoir.

Bref, un grand propriétaire de produit est un maître communicateur, a un désir insatiable de connaissance et cherche toujours à comprendre et à être compris.

Recherchez et appréciez les bons Propriétaires de Produit

Le jeu de compétences d’un bon propriétaire de produit est large et diversifié, cependant les bons font paraître cela facile. Si vous avez un état d’esprit de propriétaire de produit, il est probable que vous avez déjà de bonnes compétences de communication et que vous aimez en apprendre davantage dans de nombreux domaines.

Il est aussi probable que vous êtes le genre de personne qui donne tout pour livrer un produit et se délecte des réactions, aime la flexibilité et le changement et ne se démotive pas à la pensée de devoir refaire quelque chose pour l’améliorer.

La résolution de problèmes est un challenge et être capable de voir au-delà de l’évident, d’aller chercher l’information chez les utilisateurs et présenter ensuite quelque chose de grand peut être une joie. Cela ne signifie pas, cependant, que ce n’est pas incroyablement difficile, accablant de temps en temps, tristement inapprécié et peut-être sous-payé. Mais un grand propriétaire de produit réussira malgré ces points douloureux.

Le propriétaire de produit est la clé de voute d’un grand produit et nous devrions les rechercher et les utiliser convenablement. Vous serez stupéfié de ce qui peut être réalisé avec la bonne personne dans ce rôle.

FDF est partenaire de DantotsuPM

La magie d’histoires utilisateur courtes (User Stories)

Pourquoi dépenser du temps à rédiger, planifier et évaluer une pile de courtes histoires quand vous pouvez écrire, planifier et évaluer une unique une grande histoire ?

The Magic of Small User Stories

https://www.agilealliance.org/the-magic-of-small-user-stories/ par Dwight Kingdon

J’ai souvent rencontré des équipes qui aiment les longues Histoires Utilisateur. Pourquoi dépenser du temps à rédiger, planifier et évaluer une pile de courtes histoires quand vous pouvez écrire, planifier et évaluer une unique une grande histoire ?  Les histoires plus grosses signifient une meilleure efficacité, non ?  Pas nécessairement.

Pourquoi des histoires plus courtes ?

  • Une petite de dose satisfaction à chaque histoire complétée

    Focus : Des histoires courtes nous focalisent et nous aident à voir que la fin n’est pas trop éloignée. Il est fréquent de se sentir écrasé par les détails quand nous travaillons sur de longues histoires.  De brèves histoires génèrent aussi une satisfaction de l’équipe plus élevée; les personnes reçoivent une petite dose de dopamine à chaque fois qu’elles finissent quelque chose.

  • Transparence : Des histoires courtes fournissent une transparence et une visibilité beaucoup plus claire des progrès dans le sprint pendant le Daily Stand-Up.  Le réalisé est facile à suivre quand nous voyons une série de courtes histoires achevées; il est plus difficile d’évaluer et de visualiser le réel progrès sur une grande histoire chaque jour.
  • Relisez ce billet sur pourquoi Fibonacci

    Prévisibilité : Des histoires courtes ont tendance à aboutir vélocité plus précise et juste, ce qui réduit la variabilité et améliore la prévisibilité.  Des évaluations relatives de points d’histoire en utilisant la séquence de Fibonacci sont par définition de moins en moins précises pour de plus grandes histoires – voir “le cône d’incertitude”.  Ainsi, une histoire 13 ou à 20 points est probablement beaucoup moins prévisible que plusieurs histoires à 2, 3, ou 5 points.

  • Flexibilité : Des histoires courtes fournissent .  Elles fournissent davantage de flexibilité pour nous adapter comme nous apprenons.  Quand les circonstances changent ou que certaines histoires deviennent sans utilité, il y a moins de perte dans la réorganisation ou l’élimination d’une courte histoire.
Relisez ce billet
  • Livraison : Des histoires courtes permettent aux équipes de test de commencer à évaluer plus tôt dans le sprint et de travailler sur de plus petites portions de code.
  • Risque Réduit : Des histoires volumineuses augmentent le risque que l’équipe ne livre rien à la fin du sprint qui soit 100 % fait (Done).  La capacité de l’équipe ressemble à un entonnoir.  Quand nous essayons de forcer un grand objet (de grandes histoires) à y passer, l’entonnoir se bouche.  Par exemple, un développeur travaillant sur une grande histoire peut aussi être le seul avec le jeu de compétences nécessaires pour compléter une autre histoire critique.

Comment puis-je créer des histoires plus courtes ?

Vous trouverez des tas de bons articles sur la décomposition d’histoires d’utilisateur sur Google.  Néanmoins, voici une poignée de questions que j’ai trouvé utiles pour déterminer comment créer des histoires plus courtes :

  • 80/20
    Vidéo explicative sur Pareto

    S’il y a plusieurs résultats dans une unique histoire utilisateur, sont-ils tous nécessaires tout de suite ? Y-a-t-il un découpage 80/20 qui fournirait la majeure partie de la valeur ?  Pouvez-vous développer ces 20 % dans une autre histoire différente ?

  • Avez-vous des règles métier multiples ou plusieurs personas dans l’histoire utilisateur ? Ces règles métier peuvent-elles être construites séparément, ou les différents personas traités dans des histoires séparées ?  Des règles métier plus simples peuvent-elles suffire pour le moment pour faire marcher la solution ?
  • Est-ce que le parcours optimal peut être codé en premier sans toutes les exceptions ?  Ces exceptions peuvent souvent être relogées dans des histoires complémentaires.
  • Y-a-t-il de multiples plates-formes ou plusieurs interfaces utilisateur associées à l’histoire utilisateur ? Pouvons-nous les développer une par une ?
  • Des opérations multiples sont-elles contenues dans l’histoire utilisateur c’est-à-dire  Créer, mettre à jour, supprimer une donnée? Pouvons-nous développer une opération à la fois ?
  • Quels scénarios de test s’appliquent ? Certains scénarios sont-ils complexes et pas très critiques ?  Une première itération plus simple peut-elle être développée pour valider le design ?
  • La plupart de la complexité de l’histoire vient-elle d’exigences non-fonctionnelles comme la sécurité ou la performance ?  Si c’est le cas, l’histoire peut-elle être découpée pour d’abord faire le travail sur la fonctionnalité, puis modifiée plus tard pour satisfaire ces exigences non-fonctionnelles ?

Combien courte est « courte » ?  Quelle est la bonne taille ?

Relisez ce billet sur la méthode INVEST

Ce sont des questions très subjectives et elles dépendent de plusieurs facteurs dont la capacité de l’équipe, la durée de sprint et autres.  Un bon point de départ pour déterminer la taille idéale de l’histoire doit utiliser l’acronyme I.N.V.E.S.T.  Si vous êtes peu familiers avec cette approche, cherchez simplement “agile invest” sur votre navigateur internet pour en apprendre davantage.  Une histoire doit délivrer la valeur.  Livrer une histoire qui a peu de bénéfices perceptibles juste pour la garder petite n’a probablement aucun sens.  Au final, les histoires utilisateur plus courtes sont d’habitude meilleures que de plus longues.  Mais, le bon sens s’applique pour vous assurer qu’une histoire utilisateur peut livrer une réelle valeur et peut aussi être achevé en un unique sprint.

CertYou est partenaire de DantotsuPM

Disciplined Agile : Êtes-vous curieux d’en apprendre davantage ?

Si vous avez entendu parler de Disciplined Agile et que vous voulez en apprendre davantage…

L’équipe Disciplined Agile du PMI France se propose de vous accompagner dans cet apprentissage en lançant le Special Interest Group (SIG) Disciplined Agile.

Relisez ce billet sur les certifications Agile du PMI
A qui s’adresse le SIG ? Tous les membres du chapitre PMI France sont les bienvenu.e.s.

Comment participer au SIG ?

Répondez au questionnaire d’inscription au SIG Disciplined Agile PMI-France afin de vous inscrire.

QRP est partenaire de DantotsuPM

Comment ça marche ?

  • Les activités du SIG sont concentrées sur un forum dans un environnement technique encore en cours de définition.
  • Ce forum permettra aux membres du SIG d’échanger librement dans le cadre d‘une charte de bonne conduite (qu’en bons agilistes nous définirons ensemble)
  • Différentes activités seront proposées dont la 1ère sera un cercle d’étude.

Quand ? Dès novembre 2020

Tous les détails sur le site PMI France
CertYou est partenaire de DantotsuPM

Qu’est-ce que Agile ? Que signifiera Agile pour l’organisation ?

Démystification de Agile

  • Savez-vous ce que signifie Agile pour votre organisation ?
  • Savez-vous que faire pour devenir plus agiles ?
  • Vous sentez-vous empruntés face à la terminologie ?
  • Avez-vous entendu parler de marques Agiles comme Scrum et SAFe® sans savoir ce qu’elles signifient ?
  • Savez-vous qui impliquer dans le développement de votre approche Agile ?

Une partie clé des transformations culturelles dans lesquelles Melanie Franklin est impliquée est le désir de devenir plus agile. Un problème fréquent dans toutes ces transformations est la confusion autour de ce qu’est Agile et sa réelle signification pour l’organisation.

Dans ce webinaire, Melanie Franklin revient sur l’essentiel, expliquant les différents mots clés Agiles, les principes de travail Agile et comment cela se traduit dans les processus et un modèle de cycle de vie. Elle différencie le développement, le projet de mise en œuvre et la gestion de changement pour un travail Agile efficace. Melanie Franklin utilise aussi des exemples pour montrer comment Agile peut être appliqué à toutes sortes d’initiatives et pas seulement informatiques.

Écoutez Melanie Franklin et envoyez-lui vos questions.

CertYou est partenaire de DantotsuPM

 

Comprenez-vous vraiment votre équipe Agile géographiquement distribuée ?

Plus de la moitié de toutes les équipes agiles ne sont pas ou plus colocalisées !

Understand Your Geographically Distributed Agile Team

https://blog.gurock.com/distributed-agile-team/ par Johanna Rothman

Plus de la moitié de toutes les équipes agiles ne sont pas colocalisées, chaque personne étant à moins de 30 mètres de toute autre. Si les équipes utilisent aveuglément des approches qui assument la collocation, elles pourraient échouer. Pour éviter l’échec, comprenez d’abord la sorte d’équipe que vous avez et les données que vous pourriez devoir rassembler. Ces données fourniront la base de l’approche de votre équipe aux pratiques agiles.

Nous entendons souvent les gens décrire leurs équipes comme colocalisées, distribuées, ou dispersées. Malheureusement, trop peu de personnes se mettent d’accord sur la signification de ces mots. Et, même si vous avez vraiment une équipe non-colocalisée, le type d’équipe décidera du flux de travail et de la métrique dont vous avez besoin.

CSP est partenaire de DantotsuPM

Équipes colocalisées : Combien proche est-il assez proche ?

Votre équipe colocalisée pourrait être assise dans une pièce, la salle de travail de l’équipe. Une salle d’équipe encourage les gens à travailler ensemble, essaimer, travailler par paires, ou se regrouper comme nécessaire.

Trop peu d’équipes ont des salles d’équipe. Cependant, les membres d’équipe sont suffisamment près les uns des autres à une distance de 15 à 30 mètres pour pouvoir facilement se retrouver pour poser des questions, collaborer quand nécessaire et décider que faire en tant qu’équipe.

People at workCela demande à un adulte environ une seconde pour parcourir un mètre. Donc 15-30 mètres en environ 15-30 secondes. Si tous les membres de votre équipe sont plus distants que cela, vous avez une forme d’équipe distribuée.

Quand cela nécessite plus de 30 secondes pour poser une question, nous avons tendance à reporter la question à plus tard. Cela signifie que nous restons scotchés sur un problème, ou pire, nous passons à une autre tâche de travail. Nous augmentons notre WIP (Work In Progress), le Travail en Cours. Quand nous augmentons notre WIP, nous faisons passer moins de choses a finies (Done) par nous-mêmes et en tant qu’équipe.

Si les membres de votre équipe sont répartis sur un même étage à une distance de plus de 30 mètres, vous avez une équipe distribuée. Se déplacer à pied sur un même étage est bien meilleur que de devoir prendre l’escalier ou un ascenseur.

Si les membres de votre équipe sont sur des étages différents même dans un même bâtiment, ils font partie d’une équipe distribuée.

Dans From Chaos to Successful Distributed Agile Teams: Collaborate to Deliver, Mark Kilby et moi-même offrons des façons de penser aux équipes non-colocalisées : satellites, clusters et nébuleuse.

Équipes Satellites : La majeure partie de l’équipe ensemble, une ou deux personnes à distance

Les équipes satellites ont la plupart des membres de leur équipe à l’intérieur d’un rayon de 15-30 mètres. Une ou deux autres personnes se sentent comme si elles « tournaient » en orbite autour de la plus grande partie de l’équipe.

Nous voyons beaucoup ceci quand les développeurs et le propriétaire de produit sont dans un même bureau et que les testeurs sont à un autre étage, dans un autre bureau, ou même dans un autre pays.

Livre sur Amazon

Des équipes satellites semblent travailler comme « des bandes à part ». Parce que les membres d’équipe unis travaillent ensemble tous les jours, ils partagent l’information comme une équipe colocalisée le fait. Trop souvent, ils oublient de partager l’information avec les gens qui ne sont pas physiquement là.

Loin des yeux peut vraiment être loin de la pensée.

Parfois, des membres de l’équipe se regroupent dans bureaux ou emplacements. C’est l’équipe clusters.

Équipe Grappes (Clusters) : Les membres de l’équipe travaillent par deux ou trois

Parfois, nous voyons les développeurs ensemble dans un espace, les testeurs ensemble dans un espace différent à plus de 30 mètres des développeurs et le propriétaire de produit pourrait être sur un autre étage.

L’équipe est composée de plusieurs grappes de personnes qui travaillent ensemble dans leur petit groupe mais peu entre grappes.

Dans ce cas, les développeurs sont un cluster, les testeurs sont un autre cluster et le propriétaire de produit est un satellite. Nous appelons toujours cette équipe une équipe cluster.

Votre équipe pourrait être un cluster si les gens qui sont assis près les uns des autres représentent des fonctions différentes. La clef est qu’un certain groupe des gens se rassemble en un cluster et un autre groupe en un emplacement (cluster) différent.

Les équipes clusters ont tendance à être plus conscientes de leur tendance à devenir des bandes à part. Elles trouvent souvent des façons de collaborer pour voir le travail avancer de manière plus fluide.

Il y a une troisième sorte d’équipe, la dispersée ou équipe de nébuleuse.

Équipes de type Nébuleuse : Chacun est éloigné de tous les autres

L’avantage de l’équipe « de type nébuleuse » est que chacun a conscience de travailler à distance des autres.

Si chacun dans votre équipe travaille de son domicile ou d’un café, votre équipe est dispersée. Peut-être chacun est-il dans un bureau séparé de tous les autres. Indépendamment de l’emplacement, chaque membre d’équipe est éloigné des autres de plus de 15-30 mètres.

Quand chacun est séparé de tous les autres, l’équipe a moins de tendance de développer des « bandes à part ». D’un autre côté, il pourrait être beaucoup plus difficile de collaborer sur le travail et de le compléter (le faire évoluer vers « Fini » / Done).

Les équipes de type nébuleuse ont un aspect positif significatif: elles savent qu’elles doivent créer un espace de travail virtuel auquel chacun ait un accès équitable.

Considérez la réalité de votre équipe distribuée

Indépendamment du type d’équipe que vous avez, considérez de traiter l’équipe comme si elle était une nébuleuse. Assurez-vous que chacun ait accès à tout le code, tests et outils dont les membres de l’équipe ont besoin.

Créez un tableau qui dresse la carte du flux de travail (workflow) à travers l’équipe.

Quand je travaille avec des équipes non-colocalisées, je leur demande de dresser la carte de leur flux de valeur.

  • Qui amorce le travail ?
  • Qui prend la suite du travail?
  • Que font-ils avec ce travail ?
  • Quand le travail se bloque-t-il, se trouve-t-il dans un état d’attente ?

Après que l’équipe ait dressé la carte du flux de son travail, je lui demande d’additionner les temps de cycle. Le temps de cycle est la durée nécessaire pour que le travail passe à travers les divers états plus les temps d’attente pour être complété.

Une fois que l’équipe voit son flux de valeur et mesure son temps de cycle, elle peut se poser ces questions

  • Chacun dans l’équipe est-il dédié seulement à cette équipe, ou d’autres tâches les occupent-il brusquement ?
  • Chacun dans l’équipe a-t-il accès à la zone de travail de toute l’équipe : le code, les tests, les outils collaboratifs, quoi que ce soit dont l’équipe ait besoin pour faire son travail ?
  • Que devrions-nous faire pour créer plus d’occasions de collaboration ?

Votre équipe pourrait avoir d’autres questions basées sur le flux de valeur et le travail en cours visualisé dans le tableau.

Résolvez les problèmes de votre équipe

Beaucoup d’équipes distribuées ont de longs temps de cycle et trop de travaux en cours (Work In Progress – WIP). La première étape vers une solution pourrait être de devoir créer un tableau et limiter le WIP de l’équipe.

Quand les équipes limitent leur WIP, elles commencent à voir les divers problèmes dans leur équipe. Dans mon travail avec des équipes distribuées, je rencontre souvent ces problèmes :

  • Les membres d’équipe ne travaillent pas que pour cette équipe. Ils travaillent pour leur manager.
  • L’équipe n’a pas l’infrastructure suffisante pour collaborer.
  • L’équipe n’a pas des heures de recouvrement (horaire) suffisantes pour collaborer.

Mes recommandations sont d’abord d’identifier votre type d’équipe. Avez-vous un type d’équipe qui supporte le travail que vous voulez compléter ?

Ensuite, dressez la carte du flux de valeur et mesurez le temps de cycle de votre équipe. Voyez comment le travail circule dans votre équipe et combien de temps cela prend à votre équipe pour finir le travail et délivrer de la valeur à un utilisateur.

Finalement, commencez à évaluer les possibilités de collaboration de votre équipe.

Une fois que vous savez tout cela, votre équipe peut décider comment créer un projet Agile qui réussira.

Agile mène à l’honnêteté !

L’honnêteté se réfère à être honnête sur combien nous pouvons achever dans les délais impartis.

Https://agilechangemanagement.co.uk/2019/05/15/agile-leads-to-honesty/ par Melanie Franklin

J’aide une organisation à passer d’un management de projet prédictif Waterfall à Agile. Cela a mené à bien des discussions sur les bénéfices de Agile. En sus des bénéfices évidents de réponse plus rapide à des circonstances changeantes, la participation continue du client/business et un retour sur investissement accéléré, je veux ajouter l’honnêteté.

L’honnêteté se réfère à être honnête sur combien nous pouvons compléter dans les délais alloués. Je sais que ceux qui s’opposent à Agile se plaignent qu’il n’y ait aucune planification ou rapport mais ce n’est pas vrai et la planification qui est faite dans Agile nous donne une visibilité beaucoup plus claire de ce qui est créé, souvent à un niveau très granulaire. Cela fournit l’honnêteté sur ce que le business peut attendre suite au projet et donc l’honnêteté sur les bénéfices probables qui seront réalisés.

FDF est partenaire de DantotsuPM

Honnêteté du planning

La planification est centrée sur la production ou l’accomplissement, plus basée sur les activités. Cela mène à une honnêteté inhérente sur ce qui est créé, depuis les exigences au niveau epics aux user stories (histoires d’utilisateur) individuelles et exigences plus détaillées ensuite jusqu’aux activités spécifiques nécessaires pour livrer ces exigences.

Les équipes utilisent des techniques pour décomposer chaque livrable à réaliser en activités spécifiques, ce qui leur permet de vérifier entre elles qu’elles ont les ressources, compétences et information facilement accessibles pour leur permettre de produire le livrable. De nouveau, il y a de l’honnêteté pour savoir si vraiment tout le nécessaire est en place pour faire le travail.

Honnêteté du développement

Ce niveau granulaire de détail mène à une compréhension beaucoup plus claire du temps exigé pour développer chaque composant. Pour des produits petits, spécifiques, le temps dont on a besoin pour aller du projet initial à la revue, corriger et finir le produit peut être calculé.

Ceci est imposé par le travail en sprints souvent de seulement quelques semaines de durée. L’heureux effet collatéral de ces “décompositions de produit” est la clarté de savoir exactement ce qui va être créé avant que ce ne soit créé.

Les équipes peuvent plus facilement voir dès les premiers sprints combien de travail ils peuvent réaliser et ainsi il y a une plus grande honnêteté dans ce qu’ils promettent de livrer dans les sprints ultérieurs.

Honnêteté d’implication du business

Les propriétaires de produit (aussi connu comme des Ambassadeurs du Business) peuvent clairement voir ce que l’équipe prévoir de livrer. Cela rend plus facile pour eux de partager leurs propres idées sur les besoins devant être inclus et se projeter sur comment ils peuvent s’impliquer dans le design, le développement et les tests de chaque composant.

Cette honnêteté s’étend aussi au déploiement ou le travail de management des changements que le business devra réaliser pour se préparer à travailler de la nouvelle façon. Les pièces spécifiques de travail sont plus faciles à comprendre que les plus grands regroupements d’exigences. Il y a ainsi une meilleure compréhension de quels changements doivent être apportés “au travail comme d’habitude” (Busines as usual) pour adopter les livrables que l’équipe développe.

Melanie Franklin
Melanie Franklin (Co-Chair of the Change Management Institute UK Chapter)

Comme vous pouvez le constater, je suis fan d’utiliser Agile pour diriger une large variété d’initiatives et j’aide beaucoup d’organisations à développer leur transformation Agile.

Mélanie a dédié la dernière vingtaine d’années à aider ds organisations de toutes sortes à construire leur capacité de changement et d’adaptation.

CertYou est partenaire de DantotsuPM

les « burndown Charts » et Agile: Quoi et pour quoi faire ?

Le Scrum Trainer professionnel Ralph Jocham décrit les Burndown Charts et se concentre sur le travail dans un sprint puis dans une release.

Ralph explique comment et pourquoi ils sont utilisés et fournit des conseils sur les moyens de les exploiter au sein de vos équipes.

Voici aussi comment les Burndown Charts peuvent être utilisés dans la planification et les prévisions des releases.

CertYou est partenaire de DantotsuPM

Le guide de référence pour vos projets #Agile : « Choose Your WoW! » du PMI®

Livre – Choose Your WoW! Du PMI®

Livre sur Amazon

Ce manuel est un guide indispensable pour que les coachs et les agilistes puissent identifier les techniques (pratiques, stratégies et cycle de vie) les plus efficaces en fonction de leur situation et moins efficaces dans d’autres contextes. Ce recueil de conseils se base sur l’expérience de centaines d’organisations confrontées à des situations souvent similaires aux vôtres.

Il y a des centaines de livres qui ont été écrits sur #Agile et #Lean. Alors pourquoi un de plus?

La plupart de ces livres se concentrent sur un sous-ensemble de tout ce qui est nécessaire pour développer et délivrer de bout en bout des solutions d’une manière Agile. Il s’avère difficile d’élaborer une approche cohérente en croisant ou juxtaposant ces pratiques. De plus, il arrive que les conseils de certains de ces livres soient contradictoires et parfois peu documentés. Ils sont souvent fondés sur l’expérience et la réalité mais seulement à partir de quelques réussites et dans un contexte bien particulier probablement différent du votre.

Ce livre de 450 pages est téléchargeable gratuitement pour tous les membres du Project Management Institute®. Il est également possible d’acquérir une version papier sur Amazon.

“PMI,” the PMI logo and “Project Management Institute” are registered marks of Project Management Institute, Inc.

Management proactif des dépendances avec les approches agiles

La planification est une activité récurrente dans les approches adaptatives et les dépendances entre User Stories doivent y être identifiées.

Proactive dependency management with agile approaches

https://kbondale.wordpress.com/2019/04/07/proactive-dependency-management-with-agile-approaches/ par Kiron Bondale

Quand nous manageons des projets en une approche de livraison prédictive, l’identification des dépendances et leur suivi est fait lors de la grande planification amont en utilisant les activités après décomposition des tâches et la sagesse collective des membres de notre équipe et des principales parties prenantes. Si un changement majeur d’approche ou de portée de solution est identifié, on considère les impacts et nouvelles dépendances lors de l’analyse de la demande de changement.

Matchware est partenaire de DantotsuPM
scrum methodologie agile
Voici le diagramme du Modèle Scrum

Mais sur ces projets qui suivent un cycle de vie adaptatif, cela devient un peu plus compliqué. Étant donné la nature émergente des exigences et du design, nous sommes seulement capables de voir les dépendances dans la lumière « des phares » de notre équipe et ceux-ci pourraient seulement nous montrer les deux semaines à venir de travail. Une équipe pourrait avoir considéré “Toutes les dépendances ont-elles été identifiées et capturées ?” dans sa définition de Ready (prêt) mais cela ne signifie pas toujours qu’il est possible de satisfaire cette dépendance dans les temps.

CertYou est partenaire de DantotsuPM

Nous nous efforçons toujours de construire une équipe qui possède toutes les compétences et l’autorité nécessaire pour délivrer la pleine portée du produit ou du projet.

Mais parfois, nous avons besoin d’un expert du sujet pour un petit sous-ensemble des fonctionnalités du livrable et si nous n’identifions pas ce besoin assez tôt, nous ne serons pas capables de livrer ces fonctions au bon moment. De plus, construire une équipe complète dans de grandes organisations est souvent difficile car il y a des équipes en place avec lesquelles travailler pour construire et livrer des fonctionnalités spécifiques, mais elles ne seront pas nécessairement disponibles à la demande.

Une façon de réduire les risques associés aux dépendances qui seraient identifiées trop tard est une combinaison de revue des User Stories avec une planification avancée.

La revue des User Stories fournit une occasion de rassembler les partenaires clés de livraison et de contrôle pour considérer les histoires à un haut niveau avec le Product Owner et l’équipe de développement. Cette revue donne aux partenaires externes une chance d’indiquer quelles histoires les intéressent et aidera l’équipe à savoir avec qui elle doit se synchroniser pour compléter l’une de ces histoires. En fonction de combien ces histoires remontent dans la Story Map, ils comprendront comment elles pourraient devoir être engagées. Les membres de l’équipe peuvent aussi commencer à identifier et capturer les interdépendances entre plusieurs histoires individuelles pour aider le Product Owner dans la priorisation du Product Backlog.

Comme les histoires avec des dépendances commencent à remonter dans le product backlog priorisé, l’équipe peut activement entrer en contact avec les partenaires externes pour demander leur participation un sprint ou deux à l’avance.

La planification est une activité récurrente dans les approches adaptatives car sans cela, un partenaire externe dont votre équipe a besoin va probablement répondre par le vieux cliché : “un manque de planification de votre part ne constitue pas un cas d’urgence de ma part.

5 manières pour le #ScrumMaster d’améliorer ses réunions quotidiennes « Daily Standups »

Les Daily Standups peuvent devenir des corvées superficielles, chacun passant simplement à travers les rubriques.

5 Ways ScrumMasters Can Enhance Daily Standups

https://www.agileconnection.com/article/5-ways-scrummasters-can-enhance-daily-standups par Ajeet Singh

Les Daily Standups peuvent devenir des corvées superficielles, chacun passant simplement à travers les rubriques. C’est le travail du ScrumMaster que de s’assurer que cela n’arrive pas et que ces réunions restent utiles pour chaque membre de l’équipe.

Épuisé par la corvée du Daily Standup ?

Avec ces 5 idées, le ScrumMaster peut activement aider les Daily Standups à rester efficaces et encourager la communication, la transparence et une livraison efficace de valeur.

Les Daily Standups sont principalement un outil de synchronisation pour des équipes de développement. Elles y discutent des progrès réalisés et planifient leur travail pour les vingt-quatre heures suivantes. Le ScrumMaster en est le facilitateur et d’autres parties prenantes du projet peuvent aussi venir écouter.

Les équipes sont libres de décider elles-mêmes de comment elles veulent utiliser ces réunions de quinze minutes, mais cela met une responsabilité complémentaire sur les épaules du ScrumMaster qui doit s’assurer que la réunion produit toujours deux résultats critiques :

  1. L’équipe se concentre sur les aspects cruciaux à la progression, y compris la façon de dynamiter les obstacles et elle est capable de mettre en place un plan de travail réaliste pour la journée.
  2. Le propriétaire de produit, le Product Owner, et les parties prenantes peuvent y puiser l’information essentielle sur les progrès réalisés vers la production de code utilisable qui apporte de la valeur aux utilisateurs.

Voici 5 façons pour le ScrumMaster de mieux faciliter les Daily Standups pour atteindre ces objectifs et encourager la communication, la transparence et la livraison efficace de valeur.

CertYou est partenaire de DantotsuPM

1. Contrôlez fermement le travail en cours

Scénario : Une développeuse indique au daily standup qu’elle prévoit de travailler sur une nouvelle histoire et ne voit pas d’obstacle immédiat. Le ScrumMaster demande si l’histoire sur laquelle elle travaillait hier est finie et elle répond que l’histoire a été mise en attente en raison d’une question d’architecture technique qu’un architecte doit examiner, donc elle planifie de travailler sur autre chose.

Les points de blocage ne sont pas toujours explicitement exprimés causant de longues périodes d’attente improductives.

C’est une bonne chose que le ScrumMaster ait posé une question pour découvrir le fait qu’une histoire est en attente et qu’il y a des obstacles qui n’ont pas été discutés ou adressés sur celle-ci. Maintenant, le ScrumMaster peut suggérer que lui et la développeuse rencontrent immédiatement un architecte pour accélérer l’élimination du point de blocage pour que le travail de priorité la plus élevée puisse continuer.

Faire ceci permet de contrôler le travail en cours (Work In Progress : WIP) en se focalisant sur achever le travail qui a été engagé avant de commencer quelque chose de nouveau. Cela rappelle aussi à l’équipe de tenir le compte de combien d’histoires sont engagées en même temps et à garder le WIP sous une certaine limite qui aura été agréée avec l’équipe.

2. Encouragez la collaboration sur des activités quotidiennes

Scénario : Un testeur au Daily Scrum dit qu’il continuera à tester l’histoire débutée hier et qu’il n’y a aucun obstacle. Le ScrumMaster demande si ce test peut être achevé avant la fin de la journée et si oui ce qu’il fera ensuite. Le testeur se rend compte qu’il a oublié de mentionner qu’il prendra probablement une nouvelle histoire à tester après le déjeuner, mais il n’en a pas encore discuté avec le développeur.

Sur quelle pièce de travail, le testeur va-t-il essayer d’éliminer les imperfections quand il en aura fini avec l’actuelle ?

Le ScrumMaster s’est assuré que cette collaboration critique prend place quand on passe d’une histoire à la suivante. Le bénéfice est que, parce que l’équipe entière sait ce qui arrive, quelqu’un qui connaît de cette nouvelle histoire peut fournir l’information.

Il est essentiel que le ScrumMaster s’assure que le développement et les tests collaborent chaque jour et discutent des histoires comme elles sont mises en œuvre et testées.

3. Identifiez tous les points de blocage ou blockers

Scénario : L’administratrice de la base de données dit qu’elle a fini une histoire hier et en a pris une autre qu’elle prévoit de continuer aujourd’hui et qu’il n’y a aucun obstacle. Mais le ScrumMaster se rappelle qu’il y avait eu quelques échanges d’email récents entre cette administratrice de base de données et l’expert du sujet chez le client pour clarifier certains points sur cette histoire, donc le ScrumMaster

Il faut trouver la personne qui saura dégager le chemin.

demande si ces questions ont été résolues. L’administratrice de base de données reconnaît qu’il reste des choses à clarifier pour cette histoire et qu’il y a en réalité des blockers sur lesquels le ScrumMaster ou quelqu’un d’autre pourraient aider.

Il est important pour le ScrumMaster de suivre à la trace toutes les questions non résolues et de s’assurer que l’équipe en discute ouvertement pour que la personne qui en a la capacité puisse aider à les éliminer rapidement.

L’avantage que cette facilitation amène est que l’équipe devient plus attentive aux questions en attente de réponses et se rappelle d’utiliser le ScrumMaster pour aider à déminer ces questions.

4. Aidez l’équipe à décider de la priorité des problèmes

Scénario : Une équipe travaille sur des problèmes de production et de développement de nouvelles fonctionnalités, ce qui les force à répartir leur travail entre ces deux domaines. Le ScrumMaster pose des questions sur les problèmes majeurs de production: Sont-ils bien priorisés ? Sont-ils répartis équitablement dans toute l’équipe, ou au moins planifiés correctement pour chacun ? Et impacteront-ils la finalisation des nouvelles fonctionnalités prévues ? L’équipe se rend compte qu’elle ne parviendra pas à compléter toutes les nouvelles fonctionnalités, donc les membres discutent de la priorisation avec le propriétaire de produit pour obtenir son avis.

Le ScrumMaster devrait continuellement aider l’équipe à manager les attentes avec le côté business et mieux négocier le contenu du développement pour les prochains sprints. Ainsi, le côté métier/business sait toujours où en sont les choses et n’est jamais pris par surprise à la fin d’un sprint.

5. Soutenez des formats alternatifs de Daily Standup

Scénario : Au lieu d’utiliser le format de Daily Standup classique et répondre à trois questions (Qu’avez-vous fait hier ? Que ferez-vous aujourd’hui ? Qu’est-ce qui bloque la progression ?), l’équipe décide de discuter chaque histoire une par une, en faisant parler ceux qui sont directement impliqués. Malheureusement, cela implique que ces réunions prennent plus de temps…

Pendant la rétrospective suivante, le ScrumMaster suggère que l’équipe regarde les façons de ramener leur Daily Standup à quinze minutes. Le ScrumMaster commence aussi à surveiller l’horloge pendant les Daily Standup, aidant l’équipe à apprendre comment communiquer leurs partages plus efficacement.

Les Daily Standups risquent fort de se muer en travail de ménage superficiel

Parce que c’est la réunion de l’équipe et qu’ils devraient auto-organiser pour décider ce qu’ils veulent, le ScrumMaster devrait soutenir des formats alternatifs de Daily Standup si l’équipe pense que c’est ce qui aura du sens pour ses membres. Mais il reste toujours que la priorité majeure du ScrumMaster est de s’assurer que les objectifs du standup sont aussi atteints.

Les Daily Standups peuvent se muer en travail de ménage superficiel, chacun survolant simplement les questions. C’est le travail du ScrumMaster de s’assurer que cela ne se produise pas et que les réunions restent utiles pour chacun. Avec ces 5 idées, le ScrumMaster peut activement aider les Daily Standups à être efficaces et atteindre leur but.