Un des principes du Manifeste Agile est “la Simplicité — l’art de maximiser le travail non fait — est essentielle”. Les études du Standish Group présentées dans l’un de leurs Chaos Report montrent que 60 % des fonctionnalités développées ne sont pas ou rarement utilisés. Si vous livrez seulement les bonnes, votre client obtiendra le produit beaucoup plus rapidement et à bien meilleur marché.
Considérer de manière critique les fonctionnalités du produit que vous développez est une façon de prendre en compte ce principe. Vous pourriez appliquer ce même principe au processus que vous utilisez pour développer votre produit. Combien de règles devez-vous suivre ?
Avez-vous jamais joué au jeu de Go ?
Le Go est un jeu de société de stratégie vieux de 2500 ans pour deux joueurs, dans lequel le but est d’entourer plus de territoire que l’adversaire. Malgré ses règles relativement simples, Go est déjà très complexe. Ou pensez au « jeu de la vie » de Conway sur l’automatisation cellulaire. Juste quelques règles très simples et des résultats stupéfiants. Ajouter davantage de règles aboutira au chaos.
CSP est partenaire de DantotsuPM
J’ai lu une histoire à propos des garderies d’enfants en Israël.
Ils faisaient face au problème e que certains parents venaient chercher leur enfant trop tard. Comme solution, ils ont mis en œuvre une nouvelle règle : Si vous venez chercher votre enfant en retard, vous devez payer une amende. Suite à cette règle même encore plus de parents sont venus récupérer leur enfant en retard. Ce qui était un compromis moral (je ne peux pas y aller trop tard) est maintenant devenu une transaction financière : je paie ma dette. Les règles ne sont pas nécessairement sacrées, les principes le sont.
Si vous regardez certaines structures agiles ou façons de travailler, vous pouvez vous demander si les concepteurs vous forcent à adopter une règle ou à la transgresser. Beaucoup sont pensées pour vous aider à construire des équipes d’équipes qui développent un produit ou un service, mais ici aussi, si vous pouvez réussir à ‘simplifier’ votre architecture vers des micro services vous n’aurez pas besoin de ces structures pour « monter en échelle/volume ».
Si vous comparez le nombre de règles de Scrum avec celles de SAFe, vous pourriez vous demander si vous réussissez sortir des agile release trainsgrâce aux règles SAFe ou malgré elles ?
Si vous voulez fonder un laboratoire d’innovation ou de croissance, assurez-vous de rester à distance de la bureaucratie. Pour réduire des obstacles, exemptez le laboratoire des règles d’entreprise, des procédures, des manuels, des directives, des principes et des formats. Les approches innovantes peuvent faire sans !
Jim Johnson, rêveur et président du Standish Groupe a partagé dans un interview pour un magazine de Managers de Projet des Pays-Bas : “L’analyse des données de projet a apporté des standards, des approches et des structures, bien que j’hésite en réalité sur les standards, parce qu’ils limitent la croissance. Toutes choses bien considérées, le réflexe de construire des structures accroit les chances d’échec d’un projet technologique. Des structures sous forme d’outils de gestion compliqués, trop de règles de gouvernance, des exigences professionnelles trop étroitement définies… Des structures construites avec les meilleures intentions rendent les projets plus lents, plus chers et plus consommateurs de temps. Des structures dans lesquelles personne n’ose prendre la moindre décision.”
Si vous recherchez l’agilité, pensez à une citation de Pablo Picasso “Apprend les règles comme un professionnel afin de pouvoir les briser comme un artiste”.
Ou avec mes propres mots : Utilisez le bon sens en appliquant des approches agiles ou façons de travailler et démontrez une mentalité agile en comprenant juste la logique plutôt qu’en suivant des règles.
partagez ce billet avec vos amis, collègues et relations professionnelles
Un projet impliquant des méthodes agiles doit être basé sur une collaboration efficace avec une équipe auto-organisée qui résout les problèmes ensemble.
Un manager de projet devrait avoir confiance en l’équipe pour produire sans micro-management. PRINCE2 Agile souligne le besoin de permettre aux gens d’avancer pour produire les bonnes solutions exigées par le projet.
Et cela signifie que le comité de projet doit être clair sur ce que veut dire avoir d’une équipe « autonome » et être content que l’équipe projet fasse des changements si nécessaire. Si un élément de changement est majeur, PRINCE2 recommande de manager par exception (quand une situation dévie au-delà de ce que le comité de projet peut accepter).
#2 – Transparence, communication et exploration
Un manager de projet doit communiquer la vision du produit clairement et l’équipe doit croire en la vision pour contribuer et créer un changement de valeur.
Cela peut impliquer le fait de donner la priorité aux exigences de produit majeures en se basant sur une méthode comme MoSCoW (must have, should have, could have, won’t have for now). Puis, communiquer le résultat aux parties prenantes sur ce qu’elles obtiendront, devraient obtenir et n’auront pas.
Cette transparence avec les parties prenantes sur ce que sera le produit viable minimal les rassure sur le fait d’obtenir rapidement de la valeur pour leur investissement.
#3 – Environnement
Si Agile est un nouveau concept dans une organisation, PRINCE2 Agile introduit un « Agilomètre« . Le but de l’Agilometerest de fournir un guide vers agile qui créera un niveau de contrôle et de prévisibilité sans devenir excessivement normatif. Cela inclut l’évaluation de l’environnement et son niveau d’acceptation de méthodes et des comportements agiles.
Et, dans cet environnement, le manager de projet doit comprendre et adopter le rôle de servant leader. Il aide l’équipe à déplacer ou éliminer les points bloquants l’avancée du projet. Pour cela, l’engagement des parties prenantes est crucial.
Si l’équipe projet est novice avec les manières de travailler dites « agiles », introduisez-les à Scrum la méthode la plus utilisée. Puis, soyez clair avec les parties prenantes sur ce processus de développement et les éléments de langage utilisés. Soyez également transparent sur ce qu’ils auront et n’auront pas. Par exemple, montrez-leur la partie du produit qui est prête, mais ne les exposez pas à ce qui n’est pas encore prêt à voir ou démontrer.
CertYou est partenaire de DantotsuPM
Faire suivre cette démonstration client par une rétrospective d’équipe permet à chacun de reconnaître ce qui s’est bien déroulé avec les parties prenantes et ce qui n’a pas été. Cela crée une mentalité d’amélioration continue dans l’équipe.
#4 – Planification, suivi et contrôle
Prenez contact avec chaque personne impliquée dans le projet chaque jour.
Il est essentiel de savoir si l’équipe est heureuse de la façon dont ses membres travaillent dans un environnement agile et un manager de projet doit y devenir un facilitateur. Vous créez dans l’équipe la confiance que vous savez ce que vous faites !
PRINCE2 Agile est construit sur le concept « d’infléchissement » ou « de priorisation », produire pour créer la valeur maximale en premier. Cela représente un changement significatif dans comment les gens pensent et agissent en travaillant sur un projet. Le comité de projet doit le comprendre pour fournir une direction efficace au projet.
Il y a une logique à suivre pour travailler de cette façon
Gardez des équipes stables, n’essayez pas d’ajouter des gens pour aller plus vite
Acceptez que le client n’a pas besoin de tout : c’est le cas !
En fin de compte, PRINCE2 Agile complémente la bien établie méthode PRINCE2 mais dans un contexte agile. Ces conseils de bonne pratique prouvent maintenant pour être appropriés et applicables dans de nouveaux pays, avec de nouvelles traductions en allemand, polonais et hollandais.
partagez ce billet avec vos amis, collègues et relations professionnelles
Cette vidéo explique les principes principaux de SAFe 5.0 en cinq minutes.
Elle comprend une explication des cadences, des cérémonies et des processus de Scrum et de SAFe applicables aux équipes, aux programmes, aux grandes solutions et aux portefeuilles de projets.
Chez Intercom, nous réévaluons constamment nos processus pour construire un excellent produit, un produit que les gens trouvent de valeur et utile, un produit qu’ils aiment.
nous écoutons les clients
Une chose sur laquelle nous portons une énorme attention est la recherche. Nous embauchons des personnes avec de l’expérience dans la recherche directe et chacun dans l’équipe produit parle directement aux clients. Nous avons aussi embauché un Directeur de Recherche bien plus tôt que la plupart des autres startups : Sian Townsend qui a précédemment mené les équipes de recherche pour Google Maps.
Bien sûr, il est évident que vous devriez parler aux clients fréquemment pour essayer de comprendre leurs besoins, mais quel est le meilleur outil pour y répondre n’est pas évident.
Chez Intercom, nous pensons constamment aux choses à partir des premiers principes et très tôt nous avons appliqué ce focus sur comment nous parlons à nos clients. Nous étions les grands supporters de l’approche Jobs-to-be-Done (JTBD), mais la plupart de ce qu’a été écrit sur JTBD a été appliqué aux milk-shakes et barres chocolatées. Il y avait peu de recherches publiées sur la façon d’appliquer JTBD au développement de logiciel. Alors, nous avons créé notre propre processus basé sur ce que nous savions.
Les Personas pour l’empathie, pas pour la pensée nouvelle
Livre sur Amazon
Pendant la majorité de ma carrière j’ai utilisé des personas et des scénarios comme des outils pour comprendre les clients.
Quand je travaillais chez Google, j’ai créé des douzaines sinon des centaines de personas à travers beaucoup de projets. Nous suivions souvent la soigneusement méthode de Cooper et nous créions aussi souvent des itérations de notre propre fait. Universellement, j’ai constaté que leur valeur était limitée. Ils aidaient souvent à construire de l’empathie entre les employés qui étaient déconnectés de leurs utilisateurs, mais ils menaient rarement à des idées révolutionnaires ou fraîches de réfléchir à un problème.
Nous n’avons jamais utilisé de personas chez Intercom.
Les motivations des personnes peuvent être très similaires quelques soient les démographies
La première fois que j’ai vraiment commencé à mettre en doute la valeur des personas était quand j’ai quitté Google et rejoint Facebook. Une des choses saisissantes à propos des données comportementales de Facebook sur leurs utilisateurs était combien le comportement des gens était similaire. Les personas m’avaient amené à croire que les gens sont vraiment différents, avec des objectifs vraiment différents, mais les similarités sont beaucoup plus grandes que les différences et peu importe la démographie que vous pouvez imaginer : la race, l’âge, le genre, etc. Par exemple, les motivations d’une mère mariée avec trois enfants aux États-Unis postant les photos d’un barbecue familial est essentiellement la même que celle d’un adolescent coréen postant les photos de la fête à la maison le soir précédent. Les buts et attributs semblent totalement différents, mais leurs motivations sont les mêmes.
Les personas ne nous mèneraient jamais à un même produit conçu et construit pour ces deux audiences. Alors que les meilleurs personas se concentrent sur les buts (les buts dirigent le comportement des personnes) aussi bien que les attributs, la réalité est que la plupart des personas se concentrent seulement sur les attributs des personas et même des personas dirigés par leurs objectifs ségrèguent artificiellement ces audiences. Les personas limitent artificiellement la cible de votre produit parce qu’ils se concentrent sur des attributs plutôt que des motivations et des résultats. Cette observation a détruit ma foi en eux comme outil.
Ici les clients sont importants
Concevoir pour les motivations et les résultats est bien meilleur que concevoir pour des attributs. C’est la différence clef entre les personas et JTBD. Les personas regardent des rôles et des attributs, JTBD regarde des situations et des motivations. Les personas expliquent qui sont les gens et ce que font les gens. Mais ils jamais expliquent entièrement pourquoi les gens font quelque chose. Pourquoi les gens font certaines choses est beaucoup plus important.
Passer de ce que veulent les gens à pourquoi ils le veulent
Utilisez la technique des 5 pourquoi (relisez ce billet)
Ainsi à la mi-2013 chez Intercom, nous nous sommes demandé quel pourrait être un meilleur outil que des personas. Nous parlions à des douzaines de clients chaque semaine et notre équipe de support client parlait à des centaines de plus, recueillant des demandes de fonctionnalités et comprenant les problèmes et les contraintes de notre produit.
Avoir cette relation directe avec nos clients a été inestimable, mais il y avait deux défis que nous avions besoin de surmonter :
Les gens sont des experts dans leur problème pas la solution, mais il est plus naturel de suggérer une solution en forme d’une demande de fonctionnalité. La description d’une suggestion de solution est plus facile que la description d’un problème, mais vous devez retourner vers ces personnes avec des questions pour vraiment comprendre leur problème.
Quand ils répondent, leur réponse initiale vous dira ce qu’ils veulent, sous forme d’attributs, mais pas pourquoi cela importe. Donc vous devez continuer à fouiller dans leurs motivations.
Il était donc critique que nous découvrions quel problème nos clients essayaient de résoudre et pourquoi ils avaient besoin de le résoudre.
Et une fois que nous aurions compris le problème, comment pourrions-nous faire de toute cette compréhension quelque chose d’actionnable pour l’équipe de conception ?
Les longs rapports de recherche et les packs de transparents de présentation avec des résultats de recherche sont difficiles à mémoriser et faciles à ignorer. Nous avions besoin de quelque chose de concis, de facile à communiquer et à se souvenir. Je ne peux compter chez Google le nombre de fois où nous faisions participer des gens à la recherche, à co-créer des Personas avec nous, seulement pour ensuite les ignorer parce qu’ils étaient trop difficiles à se souvenir, trop détaillés à analyser.
Se référer aux Personas n’est pas le chemin par défaut, en fait c’est le chemin de moindre résistance. Et souvent parce que les Personas ne sont pas assez concis pour des équipes développement rapide de produit.
En dehors des Personas, un autre outil très populaire est lesUser Stories, que le mouvement de développement de logiciel Agile avait popularisées. Nous n’avions jamais utilisé de User Stories non plus. Pour commencer, elles ne proviennent pas de recherche empirique et le format est technique plutôt que centré sur le client. Elles sont formatées pour décrire la fonctionnalité à construire, plutôt que les motivations des personnes.
Histoires de travail : Capturer des situations, motivations et résultats
Après avoir réfléchi à ce problème en repartant des premiers principes, nous avons inventé des Histoires de Travail, les Job Stories. Elles ne portaient pas ce nom en ce temps-là (Alan Klement l’a trouvé plus tard pour nous) mais le processus était là et fonctionnait bien pour nous.
CertYou est partenaire de DantotsuPM
Après avoir longuement considéré JTBD, nous avons créé notre propre approche centrée sur les situations, motivations et résultats :
[ Quand _____] [je veux faire _____] [pour pouvoir _____]
‘ Quand ____ ’ se concentre sur la situation, ‘ je veux faire ____ ’ se concentre sur la motivation et ‘ pour pouvoir ____ ’ se concentre sur le résultat. Si nous avons compris la situation dans laquelle les gens rencontrent un problème à résoudre, comprendre la motivation pour le résoudre et comprendre à quoi ressemble un bon résultat, nous sommes confiants que nous construirons un produit de valeur pour nos clients.
Les Histoires de Travail sont maintenant un outil clef pour nous. Elles garantissent que l’équipe est en mode recherche, que les membres de l’équipe comprennent si bien le problème qu’ils peuvent le capturer en un format concis. Et que leur résumé du problème peut être mis en action par toute l’équipe de conception et technique.
Nous sommes impatients de vous revoir !
Avant que nous ne commencions un quelconque projet chez Intercom, nous créons un résumé d’une page pour le projet. C’est très simple et doit tenir sur une page d’A4 (qui est alors imprimée et collée sur les murs du bureau pour que les différentes équipes aient la visibilité du travail entrepris dans la société). Il a une section sur ses Histoires de Travail. Ces Histoires de Travail sont ce qui assure que nous comprenons le problème ou l’opportunité que nous abordons et elles nous tiennent focalisés sur celles-ci partout dans le projet.
Les personas y ont leur place. Dans des environnements politiques où les gens disent seulement ce que l’on veut entendre sur les besoins réels des clients, je les ai trouvés utiles pour gagner en acceptation; ils peuvent conduire un rapport plus fort avec les réels utilisateurs d’un produit.
Mais les personas sont :
Laborieux à bien créer
Trop concentrés sur les différences entre les personnes
Et difficiles à se rappeler et à référencer.
En fait :
Beaucoup de personnes avec des attributs divers ont des motivations très similaires
Ces motivations sont faciles à rechercher
Et le focus sur ce que vous construisez peut être capturé en une série de phrases courtes et mémorisables.
Si cela ne vous convainc pas, souvenez-vous que les personas contraignent artificiellement le l’ensemble du marché pour votre produit. Nous misons tout sur les Histoires de Travail.
partagez ce billet avec vos amis, collègues et relations professionnelles
Aujourd’hui, la communauté des producteurs de matériel est dans la même position que la communauté du logiciel l’était il y a deux décennies quand ils ont connu une demande business en augmentation pour des livraisons plus rapides et de qualité très élevée.
What’s new in SAFe 5? SAFe for Hardware Development!
Beaucoup d’entre nous travaillent dans les organisations qui essayent d’améliorer la livraison de produit dans des solutions qui comprennent du matériel. Pendant que SAFe offre aux développeurs de logiciels une myriade de bonnes pratiques pour accélérer l’exécution, nous n’avons eu que peu à dire aux développeurs de matériels. Jusqu’à présent.
Aujourd’hui, la communauté des producteurs de matériel est dans la même position que la communauté du logiciel l’était il y a deux décennies quand ils ont connu une demande business en augmentation pour des livraisons plus rapides et de qualité très élevée. La communauté du logiciel a inventé de nouvelles pratiques comme les méthodes Agiles et l’intégration continue, qui a mené à des innovations technologiques comme des micro-services, les plateformes et l’infrastructure « as-a-service » et le management d’interfaces pour les soutenir.
Aujourd’hui, le business exige la livraison toujours plus rapide de matériel de haute qualité et de systèmes et sous-systèmes mécaniques. La pression est maintenant sur le développement de matériel pour découvrir que de nouvelles pratiques LEAN et Agile favorisent une livraison plus rapide de solutions.
Nous voyons maintenant que des pratiques Agiles commencent à émerger dans l’industrie du matériel. Les organisations utilisent avec succès des jumeaux numériques, l’impression 3D, le Circuit Imprimé (PCB) en un jour, les Développements Pilotés par les Tests dans la conception CAO, l’intégration continue et d’autres pratiques et technologies qui accélèrent la livraison de produit et en améliorent la qualité.
La dernière mise à jour de SAFe 5 inclut de nouveaux conseils pour ceux qui font face à ces défis particuliers.
L’article Applying SAFe to Hardware Development décrit 6 principes critiques pour aider les ingénieurs de matériels à mieux comprendre comment le développement LEAN-Agile s’applique à leur contexte.
Ces principes seront immédiatement reconnaissables pour ceux qui sont familiers de SAFe
Organisez autour de la valeur pour le développement de matériel
Embrassez la variabilité et préservez des options
Construisez de manière incrémentale, intégrez fréquemment
Concevez pour le changement
Exécutez le travail par petits lots
Intégrez la qualité dans la construction de matériel
Il est grand temps que LEAN et Agile traverse le fossé pour aider le matériel et les constructeurs de systèmes cyber-physiques à répondre aux demandes de l’ère digitale. Vous pouvez lire l’article complet en anglais ici.
En novembre 2020, Jean Yves Klein et Gery Schneider (tous les 2 Disciplined Agile Chapter Champions pour la France) lancaient le « Disciplined Agile Special Interest Group » !
Géry Schneider
Ce SIG s’articule autour d’un espace Slack où les participants (une quarantaine à ce jour, tous membres du Chapitre PMI France) peuvent échanger librement à propos de l’agilité, et en particulier de Disciplined Agile.
La première initiative est le Cercle d’étude sur «Choose your WoW !» sur lequel une douzaine de participants ont rejoint Jean-Yves et Géry.
Comment ont-ils travaillé ?
Livre sur Amazon
Ils ont proposé une relecture et une analyse du livre de référence Disciplined Agile« Choose your Wow ! », téléchargeable gratuitement sur le site du PMI (pour les adhérents).
Ils ont choisi de se réunir pour 6 séances, une tous les 15 jours, les jeudis de 12h30 à 14h. Pour chaque réunion, ils planifiaient à l’avance le périmètre des discussions. Les membres avaient donc le temps de lire les prochains chapitres et se préparer à la rencontre.
Sur la base de leurs expériences, ils ont illustré les propos grâce à des schémas, des liens vers d’autres livres, d’autres conférences, d’autres sites de références, l’utilisation de ressources du PMI…
Un document comprenant toutes leurs notes, toutes les références de leurs illustrations a été rédigé collaborativement (ils sont agiles !) afin que chaque membre du groupe puisse capitaliser sur les réflexions du SIG (voire être absent à une réunion sans être pour autant trop pénalisé).
Ces explications ont été riches de sens, et une prochaine session devrait démarrer prochainement… éventuellement dès le mois d’avril.
Par ailleurs, ce cercle où l’étude n’a pas empêché la bonne humeur, a donné envie à plusieurs d’aller plus loin.
Des initiatives devraient voir le jour dans les prochains mois.
Alors, bientôt un « Disciplined Agile de Poche »… en français ?
Jean-Yves Klein
Si vous souhaitez rejoindre le « Disciplined Agile Special Interest Group » (et éventuellement participer au prochain Cercle d’étude):
Merci au Project Management Institute® (PMI®) pour cette nouvelle édition de Pulse of the Profession®, cette année dédiée à l’agilité sous toutes ses formes.
Alors que les organisations réinventent l’avenir post-pandémique, elles et leurs managers de projet doivent adopter de nouvelles façons de travailler. Pourtant, toutes les organisations n’avancent pas de la même manière ni à la même vitesse.
Au cœur de ces changements massifs, la recherche Pulse of the Profession® révèle l’émergence de ce que PMI appelle les entreprises gymnastiques (ndltr j’aurais dit gymnastes) c’est-à-dire celles qui ont appris à être flexibles et à pivoter, où et quand il le faut, tout en maintenant la structure, la forme et la gouvernance. Les entreprises gymnastiques choisissent les meilleures façons de travailler à partir d’un panel de possibilités et se concentrent sur leurs employés, sachant que la performance organisationnelle est une belle chorégraphie de performances individuelles.
Qu’est-ce qui les distingue ?
Comparativement aux entreprises traditionnelles, les entreprises gymnastiques sont plus susceptibles d’avoir un haut niveau d’agilité organisationnelle (48% contre 27%) et sont plus susceptibles d’utiliser fréquemment des pratiques standardisées de management du risque (68% contre 64%). Ces deux caractéristiques étaient des facteurs importants de réussite dans les projets pour l’ensemble de la base de répondants à l’enquête.
Les entreprises gymnastiques ouvrent de nouvelles voies en permettant à leurs employés de maîtriser de nouvelles façons de travailler, en mettant l’accent sur l’élément humain et en comprenant le rôle pivot que joue la culture organisationnelle pour mettre en œuvre toutes ces capacités.
Les retombées sont considérables.
Les entreprises gymnastiques sont à l’avant-garde dans The Project Economy, qui met l’accent sur la valeur financière et l’impact social positif, quelque soit ce que cela nécessite.
Soyez réaliste dans votre choix d’utiliser une approche Agile (ou pas) !
Pour réussir avec Agile, assurez-vous d’utiliser des critères bien réfléchis pour qualifier vos projets comme de bons candidats pour une approche Agile.
Voici des choses à considérer en établissant vos critères de qualification Agile
La priorité du projet pour obtenir les bonnes personnes
Avoir les bons membres techniques et business dédiés au projet est crucial. Agile produit rapidement des résultats avec une grande intensité pour ses participants. Agile exige les personnes business et techniques les plus critiques, celles qui sont essentielles à opérer votre business. Donc il est important de donner la priorité au temps qu’ils peuvent contribuer au projet. Accepter des compromis difficiles entre le travail de projet et les considérations opérationnelles est la clé.
Le bon niveau de connaissances
La connaissance en profondeur des secteurs business et techniques impactés par le projet est cruciale. Les experts métier travaillant étroitement avec les experts techniques de l’équipe sont au cœur de l’approche agile. La caractéristique première qui rend les méthodologies Agile agiles est la responsivité de la méthode à des besoins qui évoluent. Des personnes techniques et business bien informés doivent constamment réévaluer les livrables du projet et les besoins du business à un niveau macro et micro et prioriser les fonctionnalités nécessaires au client final. Sans connaissance et disponibilité pour réaliser ces évaluations, la base même des méthodes agiles s’effrite.
Un sponsor avec une mentalité agile
Le sponsor doit désirer participer aux fréquentes revues du produit en développement, qui sont fondamentales dans l’approche agile. D’autre part, un sponsor qui veut un ensemble linéaire, méthodique, planifiés d’objectifs livrés sur un échéancier préétabli aura du mal avec les livrables Agile. La bonne capacité de réaction de l’approche Agile aux changements de conditions du business et environnement d’apprentissage diffèrent beaucoup des méthodes traditionnelles de management de projet. Les sponsors qui résistent à la nature évolutionnaire de l’agilité créent des difficultés qui peuvent faire couler le projet.
La capacité de co-localiser ou simuler la co-localisation
Agile implique un dialogue profond, interactif et parfois difficile, qui produit de meilleurs résultats. Accroitre ce dialogue exige l’environnement le plus riche que vous puissiez créer. Co-localisez les membres de l’équipe projet si possible. Si vous ne le pouvez pas, simulez cette co-localisation avec les meilleurs outils vidéo et audio que vous pouvez trouver. Essayer de faciliter un dialogue agile avec des outils de communication sous performants ressemble à essayer de remorquer une grosse caravane avec une tondeuse à moteur. Cela n’a tout simplement aucun sens.
Synergie entre les membres business et techniques de l’équipe
Les méthodologies agiles exigent de dédier des experts métiers et techniques ouverts à essayer de nouvelles idées et à se supporter les uns les autres. Vous avez besoin d’un coach agile qui comprenne et puisse gérer la dynamique humaine et favoriser un environnement où les membres d’équipe partagent aisément leurs idées et soucis. Une équipe agile doit s’entendre bien pour réussir.
Un produit qui peut être construit itérativement
Les meilleures qualités d’Agile viennent de livrer des solutions par petits livrables en apprenant de chaque itération. En plus des produits logiciels, d’autres produits peuvent être construits de cette façon. Avec un peu de créativité, déménagements, mises en œuvre de nouveaux processus et même certains projets de construction peuvent utiliser des méthodes agiles. Si vous pensez à une façon dont votre produit final peut être construit en étapes itératives, le projet peut être un bon candidat pour une approche Agile.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
J’ai trouvé le rapport « State of Agile Coaching 2021 » très intéressant et je pense qu’il saura également piquer votre cusriosité si vous évoluez dans un environnement Agile ou qui souhaite le devenir davantage.
« Un coach agile aide les organisations, les équipes et les individus à adopter des pratiques et des méthodes agiles tout en intégrant des valeurs et des mentalités agiles. L’objectif d’un coach agile est de rendre les équipes plus efficaces, transparentes et cohésives, et de permettre de meilleurs résultats, solutions et produits/services pour les clients. Les coachs Agile ne sont plus seulement responsables d’aider les équipes technologiques, ils aident également l’entreprise à adopter l’agilité comme un changement de culture. Un coach agile ne préconise pas une méthode particulière par rapport à d’autres, mais donne plutôt aux gens les moyens de travailler plus intelligemment, plus rapidement et avec moins de risques. »
Obtenez gratuitement ce rapport
Ce rapport permet de mieux comprendre d’où ils et elles viennent, quels niveaux d’étude, quelles expériences, quels types de jobs et de contrats de travail, quelles réputations elles et ils se sont forgés…
Et vous y lirez également quels services sont fournis par les coach Agiles, comment leurs performances sont évaluées, en bref qu’en espérer et pour quels impacts ?
CSP est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Le terme MoSCoW est un acronyme tiré de la première lettre de chacune de 4 catégories de priorisation : Must have, Should have, Could have, et Won’t have.
Notre équipe se donne des objectifs trimestriels, que nous décomposons en exigences dans des sprints bimensuels. En tant que paradev (un paradev iest quiconque dans une équipe de développement ne fait pas que programmer) dans mon équipe, je travaille étroitement avec notre Product Owner pour écrire et déterminer la priorité de ces exigences.
Nous avons à l’origine commencé par utiliser la méthode de MoSCoW pour déterminer la priorité de nos exigences : Le terme MoSCoW est un acronyme tiré de la première lettre de chacune de 4 catégories de priorisation : Must have, Should have, Could have, et Won’t have.
Nous avons rapidement commencé à remarquer que la terminologie (Must have, Should have, Could have, et Won’t have) ne marchait pas idéalement dans notre contexte et nous pensions que cela causait beaucoup de frictions sur comment nous donnions la priorité et la communiquions à l’équipe. Il ne semblait pas naturel de classifier des choses comme, Must, Should, Could, Won’t car non corrélées à ce sur quoi nous devrions (Should) travailler.
En quelques sessions nous avons inventé nos propres groupements pour nos exigences en nous basant sur quand nous voudrions les voir dans notre produit : Maintenant, Ensuite, Plus tard, Jamais. Nous avons continué à utiliser ces quatre termes et nous avons constaté qu’ils ont été très bien adoptés par l’équipe car il est très naturel pour nous de penser avec ces groupements.
Le plus grand avantage à utiliser Maintenant, Ensuite, Plus tard, et Jamais, est qu’ils se transfèrent naturellement dans notre plan de produit et dans la planification de sprint.
J’ai fait quelques recherches en écrivant ce billet et j’ai trouvé Maintenant, Ensuite, Plus tard comme une approche de ThoughtWorks datant de 2012, mais je n’ai pas trouvé de lien qui contienne Jamais que nous avons trouvé très utile pour lister ce que nous reconnaissons que nous ne ferons pas.
Comment abordez-vous l’établissement de la priorité de vos exigences ?
Si vous avez aimé le livre 50 Quick Ideas to Improve User Stories mais avez des difficultés à jongler avec les 50 idées dans votre tête, les avoir en un jeu de cartes de référence est très pratique.
Nous mettons notre notre célèbre jeu de carte en libre impression, sous « creative commons ». Un excellent rappel de toutes les astuces du livre Fifty Quick Ideas To Improve Your User Stories
Et pour un peu de fun en ces temps si compliqués, je vous conseille cette petite chanson sur Scrum qui vous rappellera peut-être des souvenirs…
Hey, Scrum Master (parody of Hey, Soul Sister by Train)
Le refrain en français donne à peu près ceci:
Hé, Scrum Master, je sais que nous sommes un désastre Chaque sprint que nous sprintons et incréments que nous créons ne sont pas transparents Hé, Scrum Master, je ne veux pas manquer une seule cérémonie Scrum de ce Sprint Inspecter, inspecter et adapter, inspecter et adapter Inspecter, inspecter et adapter, inspecter et adapter
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Claude Aubry exprime son premier ressenti à la lecture de la version française (qui a été depuis améliorée) et son analyse critique des différences et des apports de cette nouvelle mouture :
Ces dernières années et particulièrement depuis le lancement du manifeste Agile en 1994, un nombre incroyable et toujours croissant d’organisations et de professionnels des projets se sont tournés vers les approches Agiles dans l’objectif d’améliorer l’exécution et le retour sur investissement de leurs projets et autres initiatives de changement.
C’est une tendance qui ne se dément pas. Le dernier rapport ‘Pulse of the Profession’ du Project Management Institute indique que 53 % d’organisations placent une forte priorité sur la mise en place d’une culture réceptive aux changements.
Depuis son introduction en 2010, AgilePM s’est vite établie comme une certification majeure pour le management de projet agile.
Développée et publiée par le Agile Business Consortium, la guidance AgilePM offre une méthodologie pratique et répétable qui trouve un équilibre idéal entre les standards, la rigueur et la visibilité exigée pour la bonne gestion de projet et les rapides changements et l’auto-organisation Agile. Il offre une structure Agile structurée et évolutive dans l’entreprise basée sur une pratique prouvée.
Il y a quelques fonctions clefs d’ AgilePM qui contribuent à sa popularité et à son succès
Une approche essayée et testée en entreprise
AgilePM Certification détails
AgilePM est essentiellement un sous-ensemble pour un manager de projet du framework Agile du Agile Business Consortium. La structure, établie au fil des 20 dernières années et régulièrement revue, combine la direction et la rigueur à l’agilité et la flexibilité actuellement exigées par les organisations.
Le cycle de vie complet du projet est adressé (au-delà du développement de produit)
AgilePM offre une approche Agile mature qui, tout en offrant agilité et flexibilité, conserve les concepts d’une livraison de projet et d’un management de projet. AgilePM va au-delà des approches de développement de produit Agiles comme Scrum.
Contrôles de qualité et de gouvernance
Un des principes sous-jacents d’ AgilePM est de ne jamais compromettre la qualité. Dans AgilePM, les critères d’acceptation de projet, de haut niveau sont agréés aux diverses étapes du cycle de vie du projet, des exigences initiales à l’étape de faisabilité, des objectifs de chaque étape de développement à la livraison du produit/solution.
Management de risque
AgilePM fournit des idées pratiques pour manager le risque, adressant directement beaucoup de risques associés aux projets. Le Questionnaire d’Approche de Projet fournit un point de départ efficace pour créer une compréhension claire et partagée des risques de projet et de leur réduction.
Rôles et responsabilitésclairs
Qui va faire quoi et avec quel niveau de responsabilité et quel rôle ?
Des personnes travaillant efficacement ensemble sont la base de tout projet réussi. AgilePM le reconnaît et assigne des rôles et des responsabilités clairs à chaque personne dans un projet, représentant le business/métier, la solution/technique, le management et les processus.
Les pratiques agiles populaires sont intégrées
AgilePM incorpore et encourage une gamme de pratiques agiles populaires pour soutenir un développement de solution efficace y compris la Priorisation Moscow, le Timeboxing et le Développement Itératif.
Relisez ce billet
Une structure et une certification globales, agnostique de l’industrie
AgilePM est une approche vraiment globale avec une certification. Les candidats de plus de 80 pays se sont embarqués pour un voyage vers la certification AgilePM. Ils représentent un large panel d’organisations, d’industries et de secteurs, de petites structures de conseil à de grandes multinationales.
L’analyse des candidats démontre l’attrait d’AgilePM dans des industries diverses.
Les huit industries les plus populaires choisies par des candidats
Information et communication (15 %)
Finance et services d’assurance (13.5 %)
Administration publique et défense (7.5 %)
Autres activités de service (6.4 %)
Activités professionnelles, scientifiques et techniques (6.1 %)
Éducation (4.8 %)
Industrie (4 %)
Santé humaine et activités d’assistance sociale (2.9 %)
Les dix premiers pays pour des examens Foundation
Le Royaume-Uni (40.6 %)
La Pologne (28.3 %)
L’Australie (7.2 %)
La France (5.3 %)
Les Pays-Bas (3.0 %)
L’Afrique du Sud (2.6 %)
L’Italie (2.3 %)
La Roumanie (1.9 %)
La Belgique (1.5 %)
La Malaisie (1.1 %)
Guide sur Amazon
AgilePM Handbook est maintenant disponible en quatre langues (anglais, français, allemand et polonais), avec des examens disponibles dans sept langues (anglais, français, allemand, polonais, chinois, hollandais et italien).
Formation et certification AgilePM
Les formations accréditées pour AgilePM sont délivrées par le réseau global d’organisations de formation accréditées (ATOs) de APMG. cliquez ici pour en savoir davantage.
QRP est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Bonjour, de nombreuses et nombreux managers de projet et agilistes me demandent où trouver des informations sur Disciplined Agile, PMI a créé un site dédié pour partager sur cette approche d’Agilité « disciplinée ».
Le Scrum Guide décrit un objectif de sprint comme “un objectif qui sera atteint dans le Sprint par la mise en œuvre de l’Arriéré de Produit (Product Backlog) et fournit des directions à l’Équipe de Développement sur pourquoi elle construit l’Incrément”. L’objectif de Sprint est un outil pour manager et concentrer les activités de l’équipe. L’équipe utilise son énergie afin de livrer la fonctionnalité exigée pour satisfaire l’objectif.
Comme outil de communication, l’objectif doit être exposé dans la langue du business/métier et indiquer succinctement 2 choses
Pourquoi le travail est fait.
Ce que le résultat accomplira.
En tant que communication, l’objectif de sprint doit parler aux parties prenantes comme aux composantes techniques de l’équipe. Définir de bons Objectifs de Sprint est difficile en partie parce qu’ils sont le reflet d’une négociation entre le propriétaire de produit (ProductOwner) etles membres techniques de l’équipe. Il faut une bonne dose de sueur de part et d’autre pour passer 3 obstacles principaux exigés pour des Objectifs de Sprint efficaces.
CertYou est partenaire de DantotsuPM
Des Objectifs de Sprint Efficaces
Tangibles. Le résultat de l’atteinte de l’objectif doit être quelque chose qui est substantiel et perceptible.
Mesurables. Le résultat d’un Sprint, par définition, est potentiellement implémentable. L’impact du résultat devrait être mesurable ou, du moins, possible à valider.
Compréhensibles. La formulation utilisée devrait ÉVITER tout charabia juridique.
Une des utilisations d’un objectif est celle d’un cri de ralliement
Si la formulation de l’objectif ne galvanise pas toutes les parties impliquées il y a un problème. De plus, les équipes utilisent l’Objectif de Sprint afin de savoir quand ils ont terminé et éliminer tout travail qui ne mène pas au résultat agréé.
Planisware est partenaire DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Bonjour, je pense que vous étiez nombreux à l’attendre et il est arrivé à la mi-novembre.
Plusieurs notables évolutions
Moins prescriptif : Scrum est ramené à un cadre minimal suffisant
Objectif de Produit, le « Pourquoi »: Chaque Sprint devrait rapprocher le produit de son objectif global.
Élimination des comportements « proxy » : Une seule équipe Scrum concentrée sur un même objectif de produit avec 3 différents jeux de responsabilités : Product Owner, Scrum Master et développeurs.
Engagements et auto-gestion : Pour le Product Backlog, il s’agit de l’Objectif de Produit, le Sprint Backlog a un Objectif de Sprint et l’Increment a une Definition of Done. La version 2020 met l’accent sur une Scrum Team autogérée qui choisit qui, comment et sur quoi travailler.
+ Lean : En effet, moins de 13 pages que je vous engage à lire et relire…
Écoutez les co-créateurs de Scrum, le Dr Jeff Sutherland et Ken Schwaber parler des mises à jour du Guide Scrum 2020 et de leur importance pour vous
Je ne sais pas depuis combien de temps vous-même utilisez Scrum mais je pense qu’un quart de siècle de vie et d’usages est une étape importante pour cette approche et cet état d’esprit.
Que Scrum signifie-t-il pour vous ?
CertYou est partenaire de DantotsuPM
Quelques pistes pour partager votre expérience :
Quand avez-vous rencontré Scrum pour la première fois ?
Sur quel projet ?
Quel fut le résultat ?
En quoi cette approche vous a-t-elle impacté ?
Au niveau professionnel ?
Au niveau personnel ?
Aujourd’hui qu’est-ce que Scrum signifie pour vous ?
Postez vos réponses dans les commentaires: texte, vidéo, images… toutes sont les bienvenues.
Michel.
Ken Schwaber et Jeff Sutherland pour un événement virtuel en live pour célébrer leurs 25 ans (de Scrum) !
Inscrivez-vous rapidement
Le 18 Novembre: Événement gratuit (nombre de places limité)
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.
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
partagez ce billet avec vos amis, collègues et relations professionnelles
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 ?
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 :
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
partagez ce billet avec vos amis, collègues et relations professionnelles
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.
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.
Un des principes du Manifeste Agile est “la Simplicité — l’art de maximiser le travail non fait — est essentielle”. Les études du Standish Group présentées dans l’un de leurs Chaos Report montrent que 60 % des fonctionnalités développées ne sont pas ou rarement utilisés. Si vous livrez seulement les bonnes, votre client obtiendra le produit beaucoup plus rapidement et à bien meilleur marché.
Avez-vous jamais joué au jeu de Go ?
Ils faisaient face au problème e que certains parents venaient chercher leur enfant trop tard. Comme solution, ils ont mis en œuvre une nouvelle règle : Si vous venez chercher votre enfant en retard, vous devez payer une amende. Suite à cette règle même encore plus de parents sont venus récupérer leur enfant en retard. Ce qui était un compromis moral (je ne peux pas y aller trop tard) est maintenant devenu une transaction financière : je paie ma dette. Les règles ne sont pas nécessairement sacrées, les principes le sont.
“L’analyse des données de projet a apporté des standards, des approches et des structures, bien que j’hésite en réalité sur les standards, parce qu’ils limitent la croissance. Toutes choses bien considérées, le réflexe de construire des structures accroit les chances d’échec d’un projet technologique. Des structures sous forme d’outils de gestion compliqués, trop de règles de gouvernance, des exigences professionnelles trop étroitement définies… Des structures construites avec les meilleures intentions rendent les projets plus lents, plus chers et plus consommateurs de temps. Des structures dans lesquelles personne n’ose prendre la moindre décision.”
Ou avec mes propres mots : Utilisez le bon sens en appliquant des approches agiles ou façons de travailler et démontrez une mentalité agile en comprenant juste la logique plutôt qu’en suivant des règles.
J’ai souvent rencontré des équipes qui aiment les longues
Transparence : Des histoires courtes fournissent une transparence et une visibilité beaucoup plus claire des progrès dans le sprint pendant le 
DantotsuPM.com 