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.
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.
Méthodes, astuces pratiques pour mieux travailler ensemble à distance comme de près et un peu de prise de recul furent les billets les plus lus au mois de Mai 2020, début du déconfinement en France.
Le principe de preuve sociale est le résultat d’un préjugé psychologique profondément enraciné. Elle se base sur la confiance envers les autres. Elle comprend la croyance que la majorité sait mieux que la personne isolée.
Selon ce principe, un individu ne sachant que faire ni que penser, aura tendance à adopter le comportement ou le point de vue d’autres personnes.
Comment identifier ce biais dans les projets et comment bien le manager ?
Pendant les formations qu’il délivre, Henny Portman a remarqué que souvent les élèves confondent les mots itératif et incrémental: il nous donne les clés pour les distinguer et les utiliser plus efficacement en fonction des projets.
Je comprends totalement la résistance de quelques membres d’équipe à la participation aux réunions Scrum quotidiennes, les Daily Scrum. Et pourtant, elles sont fort utiles si bien menées.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Quel riche et complexe métier que celui de manager de projets.
Ce mois-ci, Agilité, formations gratuites, management d’équipes que celles-ci soient à distance ou proches et comment surmonter les difficultés à manager de multiples projets en parallèle.
Le PMI a lancé un certain nombre de cours numériques gratuits (en anglais) pour que les managers de projet développent des compétences supplémentaires.
Visitez le PMI Covid-19 Resource HubPartenaire de DantotsuPM
Depuis tout jeune, on nous apprend à ne rien laisser dans notre assiette !
Une mesure fréquemment utilisée d’une équipe agile est si les membres d’équipe finissent tout ce qu’ils ont prévu dans l’itération.
Il n’y a rien mal à évaluer si une équipe est capable à la fin de terminer ce qu’elle pensait pouvoir faire. Mais on devrait s’attendre à ce qu’aucune équipe ne finisse tout à chaque fois.
Ce serait peu réaliste et cela amènerait les équipes à moins s’engager pour pouvoir tout livrer sans prendre de risque.
Souvenez-vous, travailler à distance n’est pas usuel / « business as usual ». (Et ne le sera pas pendant un long moment)
Et, vous pourriez vous poser cette question : “si personne ne vient au bureau, comment saurai-je ce qu’ils font ?”. Vous seriez étonnés : vous ne saviez pas non plus ce qu’ils faisaient quand vous étiez tous au bureau.
Utilisons les recherches sur la fidélisation des clients pour les appliquer à l’expérience des employés de nos entreprises et la rendre plus intelligente et meilleure.
Il ne semble pas y avoir assez d’heures chaque jour pour tous les réussir.
Manager des projets multiples peut rapidement devenir hors de contrôle et lâcher des yeux un instant la balle peut rapidement mener à du travail supplémentaire, des erreurs ou même l’échec.
Alors, comment managez-vous plusieurs projets différents en même temps ? Et quel est le secret est à la multi-gestion efficace ?
Hexagon est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Vous avez probablement entendu l’expression selon laquelle les gens sont seulement aussi bons que la société pour laquelle ils continuent de travailler. Eh bien, l’inverse est aussi vrai : une société est seulement aussi bonne que les gens qu’elle conserve dans ses rangs.
Le partage de données provenant de tous les recoins du business donne potentiellement une place de valeur à l’IA dans le bureau de management de projet (PMO).
Que nous nous en rendions compte ou pas, l’IA a déjà prouvé être un outil de valeur qui permet un suivi de l’avancement et de la performance de projet plus précis et plus rapide et dans tous les secteurs industriels.
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 (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
partagez ce billet avec vos amis, collègues et relations professionnelles
L’application des principes du management de projet agile et précisément de la méthode Scrum dans le processus de recherche d’emploi.
Oumaima Aziani
Oumaima Aziani est une jeune diplômée d’un master en management de projets, Consultante RH indépendante
Quand il s’agit de recherche d’emploi de façon générale et dans une situation économique instable en particulier, l’usage d’une organisation agile peut permettre un système de contrôle et d’évaluation ainsi qu’une efficacité sans pareille.
L’agilité peut être instrumentalisée dans le management de plusieurs types de projets, d’où son applicabilité facile à des domaines en dehors de celui des technologies de l’information.
L’idée de considérer la recherche d’emploi comme un projet permet de voir le statut de chercheur d’emploi sous un angle différent. Le fait de percevoir cette période comme une phase où l’on travaille sur soi, permet de nous donner une raison d’entamer ce projet avec plus d’enthousiasme et de structure. Pas besoin d‘avoir une certification Agile pour adopter les recettes agiles.
Avant d’entrer dans les détails de comment les différents principes du manifeste agile peuvent accélérer le processus de l’obtention de son premier emploi, soulignons d’abord comment les valeurs agiles peuvent être un bon fondement pour ce type de projet.
Il s’agit de quatre valeurs fondamentales qui encadrent le fonctionnement de n’importe quel projet agile, à savoir :
Les individus et leurs interactions plus que les processus et les outils
La recherche d’un emploi passe avant tout par les interactions, les technologies qui nous permettent aujourd’hui de chercher un travail peuvent être très utiles mais le contact avec les gens peut jouer un rôle crucial dans la collecte des informations surtout pendant les phases initiales du projet.
Des logiciels opérationnels plus qu’une documentation exhaustive
Aujourd’hui nous avons des logiciels pour tout, de la création d’un CV « optimisé » à la sélection des emplois qui correspondent à nos capacités et à la gestion des candidatures, on peut vraiment tout faire en ligne. Il faut donc en profiter pour démontrer son talent et faire preuve d’originalité. Que ce soit pour des emplois administratifs ou de bureau, des emplois dans le commercial ou la vente de détail, des emplois dans les transports ou la logistique ou autres, il y a des plateformes spécialisées pour tous types de profils. Ajoutons à ceci des outils comme LinkedIn qui facilitent la communication directe avec les entreprises et les administrations publiques.
La collaboration avec les clients plus que la négociation contractuelle
Le mot collaboration inspire avant tout l’idée d’un échange honnête. La digitalisation des processus de recrutement au sein de certaines organisations a affaibli la dimension humaine de la gestion des ressources humaines. Les recrutements basés sur des recherches de mots-clés, des logiciels de filtrage des CV et autres solutions digitales ont avant tout réduit la possibilité d’un bon vieux dialogue en face à face entre deux êtres humains. Mais si l’expérience du confinement nous a appris une chose, ça serait que la technologie nous a aussi permis de rester connectés et surtout de continuer à collaborer dans de bonnes conditions.
L’adaptation au changement plus que le suivi d’un plan
Le marché de l’emploi peut être très vulnérable au changement. L’économie toutefois ne cesse d’évoluer et même dans un contexte de crise, il y a toujours moyen de trouver sa niche et de s’imposer comme le/la candidat(e) optimal(e) pour le poste.
Un cadre pour réussir sa recherche d’emploi
Ces valeurs sont des piliers du manifeste agile, elles forment un cadre théorique de référence dont découle donc plusieurs principes démontrant de façon plus détaillée comment l’agilité permet une gestion efficiente des projets étape par étape.
L’un des principes phares de la méthodologie Scrum est la mise en place d’un plan d’action flexible qui permet d’intégrer les retours de toutes les parties prenantes dans les étapes suivantes du projet dans une logique de perfectionnement continu. Cela voudrait dire que d’un côté il faut toujours essayer d’avoir un feedback de la part des recruteurs, il faut chercher à répondre à la question : Pourquoi ma candidature n’a-t-elle pas aboutit ? La réponse à cette question peut éclairer encore plus l’étape suivante et faciliter notre adaptation aux besoins des recruteurs.
Ce qui nous mène à un autre principe du manifeste agile, qui est l’acceptation du changement, que ce changement soit une crise économique, une pandémie ou les deux. Avec une analyse assez poussée des besoins du marché, on se donne la possibilité d’adapter son skillset à la situation économique et aux besoins des recruteurs. En optant pour l’agilité, on exploite le changement pour se donner un avantage compétitif. [1]
Le manque de structure dans le travail qu’effectue un chercheur d’emploi peut être compensé par le développement d’un ensemble d’indices quantitatifs permettant d’évaluer l’évolution de sa quête. Bien que cela puisse sembler compliqué, les KPIs (Key Performance Indicators) permettent d’évaluer le succès ou pas du projet. Dans le cadre d’une recherche d’emploi ces indices quantifiables peuvent être : Le nombre de retours que l’on reçoit; le nombre d’entretiens téléphoniques ou physiques que l’on passe; l’efficacité des candidatures spontanées à déclencher un retour de la part des services des ressources humaines.
Quand il s’agit de l’intégration dans un certain milieu professionnel, le savoir être compte tout autant que le savoir-faire. Ça commence par s’entourer par des personnes actives et motivées et se reposer sur un networking solide qui permet toujours d’avoir plus de pistes pour faciliter sa recherche.
Un autre principe important est la favorisation des échanges directs. Quand on est intéressé par un certain domaine ou une certaine entreprise, c’est toujours une bonne idée d’essayer d’avoir un contact direct avec le/la responsable ressources humaines afin d’adapter ensuite sa candidature au profil qui l’intéresse.
Et enfin, l’essence même de l’agilité repose sur l’amélioration de ses compétences et l’évolution continue. Que ce soit par la maîtrise de nouveaux logiciels, l’apprentissage de nouvelles langues ou tout simplement en s’informant en profondeur sur un sujet en lien avec notre domaine.
Apprendre de nouvelles choses est primordial pour rester à jour et s’adapter plus facilement à la reprise de la vie active.
Le management de la productivité peut s’avérer très difficile, particulièrement pour les procrastinateurs (les indécis qui remettent tout au lendemain).
Kanban for Procrastinators: From Last-Minute to First-Minute Productivity
En fait, autour de 20% des adultes ont été aux prises avec la procrastination au moins une fois dans leur vie. Même les plus fortement motivés et qui réussissent bien y font face. Remettre une tâche à plus tard, comme si ce comportement pouvait la faire disparaitre (ou s’auto-compléter magiquement). La douloureuse vérité est que cette temporisation nous fait perdre du temps de façon sans précédent. Faites-moi confiance, je le sais d’expérience personnelle.
Opter pour la productivité de dernière minute a cependant certains côtés positifs.
Comme les procrastinateurs ont tendance à remettre les choses à plus tard, il y a une forte chance qu’ils sachent exactement que faire et comment le faire. Et à cause de leur approche spécifique du management de la productivité « Faire les choses au moment où ils doivent absolument les faire », ils ont tendance à trouver les solutions les plus faciles et les plus rapides à la plupart des problèmes. Donc, quand ils se mettent vraiment au travail et complètent leurs tâches, ils le font dans des explosions d’énergie, de concentration intense et de brillante efficacité.
Bien que la procrastination puisse sembler inoffensive et positive, toujours choisir de remettre à plus tard au lieu de s’y mettre ici et maintenant endommage notre productivité.
Alors, pourquoi continuons-nous à remettre à plus tard ? Les raisons peuvent être diverses. Depuis être si perfectionnistes et tant magnifier l’importance des erreurs et échecs que certaines personnes évitent complètement une tâche. Jusqu’à avoir un manque d’information et ne pas savoir où commencer. Ou encore choisir de petites tâches et avoir le sentiment d’être occupé et reporter des tâches plus grandes, plus importantes. Ou bien perdre sa concentration à cause d’appels téléphoniques et emails, ou par simple manque de motivation.
Bien que, le plus généralement, ce soit en raison d’une mauvaise gestion du temps et de sa productivité, on croit qu’il nous reste largement assez de temps pour achever la tâche. Le tout, selon mon expérience personnelle et l’expérience d’autres procrastinateurs.
Heureusement, sortir de cette boucle de productivité de dernière minute et réaliser un changement est possible.
Tout ce dont vous avez besoin est la volonté et la persévérance. Le choix et l’utilisation du bon outil en support de votre équipe sont aussi d’une grande aide. Donc plongeons dans les détails et pour commencer, considérons les bénéfices de la productivité dès les premières minutes.
Utilisez Kanban pour combattre la procrastination
Beaucoup de personnes se demandent si l’utilisation d’un outil spécifique de management de projet peut réparer leur gestion de la productivité. Eh bien, il le peut. Peu importe combien intangible cela peut sembler, utiliser une méthodologie spécifique et ses outils peuvent énormément changer la façon dont vous réfléchissez et ressentez l’achèvement de vos tâches. En outre, cela peut vous aider à être plus organisé et responsable de terminer le travail sur lequel vous vous êtes engagés.
L’une de ces méthodologies qui peut changer la façon dont vous approchez l’achèvement des tâches est Kanban. Kanban est une méthodologie qui utilise la visualisation et les limites de travail en cours, Work In Progress / WIP, comme les 2 composants principaux pour amener à la productivité. Mais laissez-moi la décomposer et vous expliquer comment utiliser Kanban pour combattre la procrastination.
CertYou est partenaire de DantotsuPM
Ayez une image claire du travail à venir
La mise en œuvre de Kanban commence par la visualisation du flux complet de travail (le workflow) sur un tableau Kanban. Prenez votre processus et créez une colonne pour chacune de ses étapes. Cela vous aidera à acquérir une meilleure vue d’ensemble de comment les tâches s’enchainent et comment elles sont connectées l’une à l’autre.
Après avoir visualisé le workflow, pour l’étape suivante, créez des cartes Kanban pour toutes les tâches.
Remplissez votre arriéré (backlog) et distribuez le travail en cours dans les colonnes respectives. Prenez les tâches les plus grandes et divisez-les en morceaux plus petits. Assignez-les alors aux bonnes personnes. Des tâches plus petites se déplacent plus rapidement dans le tableau Kanban et vous aurez le sentiment que vous accomplissez constamment quelque chose. Et le projet ne semblera plus si gigantesque.
Voici les premiers pas vers la mise en place d’un système de gestion de productivité efficace. Une fois que vous aurez tout le travail clairement visible, il sera plus facile d’organiser le travail. Et cela vous libérera (et l’équipe) de devoir vous rappeler ce que vous devez faire ensuite.
Hexagon est partenaire de DantotsuPM
Réduisez le multitâche et limitez les interruptions
Quand vous placez le processus entier et les tâches en cours sur un tableau Kanban et l’affichez publiquement, chacun en prendra davantage conscience et se sentira plus responsable. Cependant, si vous voulez réduire efficacement le nombre de distractions et réduire au minimum le multitâches, vous devez ajouter une dimension importante à votre tableau Kanban : les limites de WIP (le travail encours).
Les limites de WIP sur votre tableau Kanban limitent le nombre de tâches que vous pouvez prendre de l’arriéré à l’instant T.
à télécharger en ligne
Elles sont cruciales pour atteindre un nombre de tâches finies, au lieu de constamment en commencer de nouvelles. De plus, l’approbation sociale et la récompense sociale liée à terminer votre travail dans les temps et contribuer à un travail bien fait vous motivent tant, qu’elles peuvent même surpasser l’importance d’une récompense financière. En conséquence, les membres d’équipe sont « forcés » de travailler sur une tâche à la fois, restant ainsi plus concentrés et devenant plus productifs.
Répartissez pour vaincre
Vous pouvez travailler excellemment bien sous la pression. Vous l’avez prouvé pendant votre période de procrastinateur. Mais, vous n’êtes pas tout-puissant. Et il n’y a aucun nécessité de faire tout par vous-même quand vous faite partie d’une équipe. Il y a toujours quelqu’un dans votre équipe qui connait la meilleure solution à votre problème. Aussi, pourquoi ne pas demander de l’aide et gagner du temps ?
La collaboration fait partie de la philosophie de Kanban, mais la délégation aussi.
Suivez soigneusement comment les tâches sont décomposées et assignées et si vous remarquez qu’il y a un déséquilibre, dites-le. Chacun devrait se voir assigné autant de travail qu’il peut en achever et des tâches pour lesquelles il est qualifié. Communiquez régulièrement avec votre équipe pour vous assurer que personne n’est surchargé, sous-chargé, ou a été assigné du travail hors de portée de ses capacités. La répartition appropriée du travail est cruciale pour établir un système de management de productivité efficace.
Le management de la productivité commence par VOUS
La vérité est qu’aucun outil ni méthodologie que vous choisissez ne changera magiquement la façon dont vous approchez votre travail à moins que vous ne vouliez vraiment l’utiliser et persévérer dans ses pratiques et principes.
Aussi difficile que cela puisse être de changer des habitudes existantes, c’est possible.
Une fois que vous y mettez votre volonté, vous pouvez changer la manière dont vous faites des choses. Donnez une vraie chance à un système de management de productivité et ayez la discipline de l’utiliser régulièrement jusqu’à ce qu’il devienne votre nouveau normal.
Même si utiliser Kanban pour visualiser le travail qui se dirige vers vous peut sembler contre-intuitif pour combattre la procrastination, faites-moi confiance, ça ne l’est pas.
Avoir la vue d’ensemble, comprendre où vous en êtes et combien votre rôle est crucial, peuvent en réalité augmenter votre volonté de vous engager.
Quand le travail de l’équipe entière est affiché sur le tableau, cela accroit la responsabilité. Les gens sont motivés pour compléter leurs tâches plus rapidement, donc la procrastination se réduit. Et vous vous déplacez lentement de la productivité de dernière minute à celle des premières-minutes.
Quelques autres billets parus précédemment sur ce sujet
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 :
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.
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.
partagez ce billet avec vos amis, collègues et relations professionnelles
Pendant les formations qu’il délivre, Henny Portman a remarqué que souvent les élèves confondent les mots itératif et incrémental: il nous donne les clés pour les distinguer et les utiliser plus efficacement en fonction des projets.
Grâce à ces petites vidéos, Henny nous fait mieux comprendre la relation entre le développement progressif et itératif.
QRP est partenaire de DantotsuPM
Il commence par une comparaison entre une approche prédictive, en cascade / waterfall, et une approche agile pour construire une application de paiement en ligne
Dans un second temps, Henny positionne waterfall et agile dans une matrice incrémental versus itératif et montre ce qui se passe dans chaque quadrant.
Pour finir, Henny explique produit minimal viable (MVP) et produit minimal commercialisable (MMP) et montre comment ils s’inscrivent dans les différentes approches et cartographie.
Je comprends totalement la résistance de quelques membres d’équipe à la participation aux réunions Scrum quotidiennes, les Daily Scrum. Et pourtant, elles sont fort utiles si bien menées.
Je comprends totalement la résistance de quelques membres d’équipe à la participation aux réunions Scrum quotidiennes, les Daily Scrum. Je n’aime pas non plus les réunions. Mais, certaines réunions sont utiles et justifient l’investissement de notre temps. Je mets les réunions Daily Scrum bien-dirigées dans cette catégorie.
Dans cet article, je partage avec vous comment je traite quatre objections fréquentes à la participation au Daily Scrum. Je partage ensuite quelques attributs d’un Daily Scrum bien-mené pour qu’il n’y ait plus aucune objection à participer.
4 objections fréquentes
1. Nous parlons déjà beaucoup
Pas de temps à « perdre » alors que nous discutons déjà énormément.
La première objection au Daily Scrum est qu’une personne insiste sur le fait que les membres d’équipe parlent déjà fréquemment l’un avec l’autre et donc le Daily Scrum est une surcharge inutile.
Quand j’entends cette objection, j’y résiste en reconnaissant que les membres de l’équipe parlent vraiment fréquemment en effet l’un avec l’autre. Mais rarement parlent-ils tous ensemble.
Le Daily Scrum fournit cette opportunité. Pour beaucoup d’équipes, c’est l‘unique fois chaque jour où chaque membre d’équipe est capable de parler à tous les autres membres de l’équipe.
2. Rien d’important n’est jamais discuté
Une deuxième objection commune au Daily Scrum vient de membres d’équipe qui estiment que des Daily Scrum sont inutiles parce que rien d’important n’y est jamais discuté.
Repositionnez les attentes
On ne priorise pas la discussion pour discuter des plus importants problèmes en premier.
La première chose je fais quand je suis face à cette objection, est de poser une attente appropriée sur ces réunions avec l’opposant. Je suis très clair sur le fait que je ne m’attends pas à ce que quelque chose d’important soit abordé chaque réunion. Certains Daily Scrum s’avèrent vraiment être assez inutiles, ceux où chacun a réalisé un progrès convenable mais sans quoi que ce soit de remarquable hier et personne n’a de question sur le travail du jour.
Mais, la plupart des Daily Scrum remontent vraiment quelque chose d’utile pour l’équipe. Et l’idée est que les nombreux Daily Scrum où des choses importantes sont discutées compensent les réunions moins fréquentes où rien d’important n’est discuté.
Déterminez si l’objection est valide
La deuxième et plus importante chose que je fais quand j’entends cette objection, est de considérer si elle est recevable. Elle peut l’être. S’il en est ainsi le Scrum Master devrait la prendre en compte comme un indicateur que les réunions pourraient être améliorées.
Prenons le temps de considérer objectivement si la question est pertinente.
Les erreurs fréquentes qui rendent cette objection valable incluent laisser des participants blablater hors sujet, laisser la réunion durer trop longtemps, ou avoir une bande d’individus qui ne sont pas vraiment une équipe. Cette dernière erreur arrive quand « une équipe » est composée d’individus travaillant sur des projets totalement sans rapport.
3. Ne pourrions-nous pas juste le faire par email ?
Certains membres d’équipe ne font pas d’objection au concept d’engager avec leurs coéquipiers quotidiennement, mais au lieu de cela, objectent à en faire une réunion. Ils demanderont souvent d’abandonner le Daily Scrum en faveur d’un email quotidien de chaque personne adressant les mêmes questions habituelles du Daily Scrum.
J’ai rarement vu ceci fonctionner. Le plus grand problème est que la plupart des personnes ne lisent pas les emails. Ou, si elles le font, c’est un jour ou deux plus tard. Cela rend l’équipe moins réactive aux problèmes.
De plus, mener un Daily Scrum par email perd tous les bénéfices de la discussion dans l’instant présent qui devrait faire partie des réunions.
Et avec des outils comme Slack et semblables ? Vous penseriez peut-être que ma réponse serait la même que pour l’email. Cependant, j’ai vu des équipes mener avec succès l’équivalent de réunions Daily Scrum en utilisant Slack.
Je ne sais pas si c’est la nouveauté de tels outils ou quelque chose de fondamentalement différent entre la messagerie instantanée et l’email. Je ne favorise toujours pas de remplacer l’interaction vivante d’un Daily Scrum avec un équivalent Slackpour la majorité des équipes. Mais pour certaines équipes, particulièrement celles qui sont fortement géographiquement distribuées, cela semblent vraiment marcher de manière adéquate.
4. Les réunions durent trop longtemps
Une quatrième et finale objection que vous entendrez consiste en ce que les réunions durent trop longtemps. Naturellement, vous voudrez prendre cette plainte au sérieux si vos réunions prennent plus longtemps que la norme de quinze minutes prescrites par presque tous les partisans de Scrum.
Mais si vos réunions finissent bien dans la limite des quinze minutes, j’ai constaté que la meilleure réponse à cette plainte est de demander à tout opposant combien de temps il pense serait approprié.
Vous obtiendrez une réponse utile particulièrement si vous incluez quelques-uns des bénéfices de la réunion en posant la question. Par exemple, vous pourriez demander, “Combien de temps pensez-vous serait approprié chaque jour pour nous tenir tous synchronisés, éviter les problèmes de communication, fournir de la visibilité sur ce que fait chacun d’entre nous, identifier et corriger des erreurs, construire la confiance et fournir un sentiment d’accomplissement ?”
CertYou est partenaire de DantotsuPM
7 Attributs d’un Daily Scrum bien mené
Les conseils ci-dessus aideront à surmonter les objections les plus communes que des membres d’équipe peuvent avoir à participer au Daily Scrum. Encore mieux, serait de conduire ces réunions si bien que les membres d’équipe les valorisent. Voici sept attributs d’un Daily Scrum bien mené.
1. Tenez les réunions chaque jour au même horaire et endroit
Vous voulez rendre ces réunions aussi faciles que possible. Pour la plupart des équipes, cela signifient les tenir à la même heure et au même endroit à chaque fois.
2. Débutez la réunion à l’heure
Je suis plus à l’heure que qui que ce soit d’autre. J’ai une fois dû me raisonner d’appeler un docteur quand j’ai réalisé que j’aurais une minute de retard à son cabinet.
Mais je reconnais tout de même qu’arriver quelques minutes en retard à une réunion qui dure toute une journée n’est pas une bien grande affaire. Être cinq minutes en retard à une réunion de huit heures représente 1 % du temps de la rencontre.
Mais être en retard à un Daily Scrum est une affaire beaucoup plus importante. Si les réunions commencent 5 minutes en retard chaque jour, les membres d’équipe qui sont arrivés à l’heure auront perdu plus de 20 heures sur l’année à attendre que la réunion puisse commencer.
3. Respectez la limite de 15 minutes
Il y a une raison pour laquelle beaucoup d’équipes conduisent les Daily Scrum en se tenant debout : Cette position nous aide à rester conscient du temps et facilite les réunions brèves.
4. Identifiez les problèmes mais ne les résolvez pas pendant la réunion
Une bonne pratique commune est de discuter (et avec bon espoir résoudre) des problèmes immédiatement après la réunion. Idéalement cela peut être fait par le sous-ensemble de l’équipe nécessaire pour aborder ces problèmes; les autres membres d’équipe sont alors encouragés à retourner à leurs bureaux.
5. Gardez les participants sur le sujet
La plupart des équipes suivent l’approche d’avoir chaque personne exposer ce qu’ils ont accompli depuis la dernière réunion, ce qu’ils feront avant la réunion suivante et tout problème les ralentissant.
Toute discussion hors de ces sujets devrait être sévèrement limitée.
6. Les règles sont rappelées par l’équipe entière, pas seulement le Scrum Master
Quand le Scrum Master est le seul à imposer les règles de l’équipe lors des réunions, la réunion semble être tenue pour le Scrum Master. Cela ressemble à rapport d’activités où chaque participant fournit le statut seulement au bénéfice du Scrum Master.
7. L’équipe complète et seulement l’équipe participe
Chacun dans l’équipe devrait participer aux Daily Scrum. On devrait permettre à des externes à l’équipe d’observer la réunion. Ils devraient être découragés de contribuer à la discussion pendant la réunion à moins qu’un membre d’équipe ne lui pose une question courte.
Une fois que l’on conclut un Daily Scrum, mais avant que les participants ne se dispersent, beaucoup d’équipes demanderont aux observateurs s’ils ont des questions ou commentaires. Le Scrum Master ou un sous-ensemble de l’équipe peuvent rester et adresser ceux-ci. La clef est que ces commentaires d’observateur restent à l’écart du Daily Scrum.
Quelle est votre expérience ?
Les membres d’équipe peuvent sans aucun doute avoir des objections autres que les quatre les plus communes que j’ai adressées ici. Et il y a certainement des choses complémentaires importantes pour un Daily Scrum bien mené que les sept attributs essentiels que j’ai décrits.
Quelle est votre expérience ? Quelles objections avez-vous entendu et comment les avez-vous surmontées ? Partagez s’il vous plaît vos idées dans les commentaires.
partagez ce billet avec vos amis, collègues et relations professionnelles
Depuis tout jeune, on nous apprend à ne rien laisser dans notre assiette !
Une mesure fréquemment utilisée d’une équipe agile est si les membres d’équipe finissent tout ce qu’ils ont prévu dans l’itération.
Il n’y a rien mal à évaluer si une équipe est capable à la fin de terminer ce qu’elle pensait pouvoir faire. Mais on devrait s’attendre à ce qu’aucune équipe ne finisse tout à chaque fois.
Ce serait peu réaliste et cela amènerait les équipes à moins s’engager pour pouvoir tout livrer sans prendre de risque.
Matchware est partenaire de DantotsuPM
Des attentes excessives peuvent entrainer des dysfonctionnements
Considérez une équipe dont le patron (le PDG) leur a dit que s’il leur arrivait d’échouer à tout finir, il “prendrait des actions correctives, jusqu’à et incluant probablement l’arrêt brutal du projet.”
Cette équipe ne va pas aller chercher une masse excessive de travail dans ses itérations. Les membres essayeront d’en choisir suffisamment pour ne pas être traités de paresseux, mais pas trop pour ne pas risquer de ne pas tout faire.
CertYou est partenaire de DantotsuPM
Une cible appropriée
Je trouve qu’un bon objectif pour une équipe est de finir tout ce qu’ils disent qu’ils feront environ 80% du temps. C’est un bon degré de prévisibilité pour le business sans être impossible à tenir par les équipes.
Pour être vraiment clair, une bonne équipe agile devrait finir 100% de ce qu’elle prévoit dans 8 itérations sur 10. Je ne dis pas qu’une équipe devrait finir 80% de son travail prévu à chaque itération. C’est très différent.
80% du temps dans la cible est déjà très bien.
Tout faire à chaque fois sera impossible pour des équipes fréquemment interrompues. Si une partie significative du travail de votre équipe est de répondre rapidement aux problèmes, vous pouvez vouloir vous donner une cible de pourcentage inférieur.
Ne le planifiez pas si vous ne pensez pas que vous le réaliserez
En essayant de finir 100% de son travail, 80% du temps, l’équipe devrait ressentir qu’ils vont réussir tout en comprenant, avec réalisme, qu’ils ne le feront pas à chaque fois.
J’aime y penser comme analogue au basketteur lançant le ballon. Le joueur ne devrait pas lancer le ballon à moins qu’il ne pense qu’il marquera le panier. Mais, même le meilleur basketteur comprend que tous ses lancers ne peuvent entrer dans le panier.
Un bon basketteur peut réussir 40 à 50% de ses lancers. Ce n’est pas suffisamment de prévisibilité pour la plupart des équipes, voici pourquoi je recommande de viser les 80%.
Quelle est votre expérience ?
Où en est votre équipe sur compléter ce qu’elle a dit qu’elle ferait ? Partagez s’il vous plaît vos idées dans les commentaires ci-dessous.
partagez ce billet avec vos amis, collègues et relations professionnelles
Le cône d’incertitude est la forme géométrique que donne la représentation graphique de l’exactitude des estimations par rapport à l’avancement du projet.
Il incarne l’idée que les estimations faites au début d’un projet seront limitées dans leur exactitude et quand vous travaillez à réduire l’incertitude dans le projet, les estimations peuvent devenir plus précises au fil du projet. Au cours du projet, le concept, les exigences et la conception vont s’étoffer pour donner une bien meilleure idée de la faisabilité, des délais et des coûts du projet.
En observant le cône d’incertitude, vous pouvez aisément comprendre et montrer à vos clients pourquoi vos estimations initiales de projet ne seront pas exactes, et comment vous pouvez les améliorer avec eux.
Vous pouvez également utiliser le cône d’incertitude pour donner un pourcentage estimé de leur exactitude en fonction du temps et défendre vos estimations si elles sont remises en question à une date ultérieure.
En donnant une limite inférieure et supérieure à votre estimation, vous pouvez clairement communiquer l’incertitude inhérente à l’estimation. Si la personne qui reçoit l’estimation n’est pas satisfaite de la précision de la fourchette donnée, vous pouvez utiliser cela pour demander davantage de temps ou de ressources pour éliminer une partie de l’ambiguïté et fournir une fourchette d’estimations plus resserrée.
Matchware est partenaire de DantotsuPM
Selon ma propre expérience Agile/Scrum, quand l’histoire utilisateur, la User Story, devient éligible à entrer dans une session de sprint planning c’est qu’on l’a déjà suffisamment analysée pour pouvoir donner une estimation relativement fiable. Nous nous trouvons entre les exigences détaillées et le design détaillé du cône d’incertitude.
CertYou est partenaire de DantotsuPM
partagez ce billet avec vos amis, collègues et relations professionnelles
Les projets agiles sont basés sur le concept que livrer une solution imparfaite au business le jour promis est plus important que livrer une solution parfaite en retard.
Avec Agile, tenir vos promesses sur quand quelque chose sera disponible pour être utilisé en production est au cœur de la réalisation de bénéfices. Chaque élément fourni, même s’il a un nombre minimal de fonctionnalités peut résoudre un problème métier. Focalisez votre équipe sur faire utiliser leur livrable en production, en sachant qu’ils pourront ajouter davantage de fonctionnalités plus tard.
Il y a une fausse idée répandue qui est que ceux travaillant dans des équipes Agiles ne planifient rien.
Alors que les compétences de planification y sont plus importantes que dans l’approche prédictive « en cascade » (PRINCE2 ®) pour les projets parce que :
La planification est plus fréquente
La planification est faite en collaboration, impliquant chacun qui contribue au projet
Les plans y sont un mécanisme essentiel de suivi du progrès
QRP est partenaire de DantotsuPMaux fausses croyances sur Agile
Pour ces raisons, les compétences de planification sont critiques au travail Agile efficace. La planification détaillée du projet de bout en bout au début ne fait pas partie Agile. Au lieu de cela, il y a la planification fréquente et la re-planification pendant tout le cycle de vie du projet. Quand un élément de la solution est livré au business, le focus se porte sur la planification de la livraison suivante.
Objectifs de la planification
Pour respecter l’importance de planification, j’encourage mes équipes à se mettre d’accord sur un jeu commun d’objectifs pour leurs sessions de planification.
Utilisez ceux-ci pour débuter avec votre équipe :
Assurons-nous que nous livrons une solution utilisable et de valeur
Assurons-nous que nous n’avons rien oublié
Donnons la priorité au travail le plus important en premier
Allouons le travail aux meilleurs de l’équipe pour le faire
Clarifions l’ordre/le séquencement pour réaliser des économies d’efforts
Créons un visuel qui permette aux autres de voir ce que nous faisons et quand afin qu’ils puissent aligner leur travail avec le nôtre
Utilisons ce visuel pour fournir un suivi facile de notre progression sans devoir écrire de rapport d’avancement
CertYou est partenaire de DantotsuPM
Ordre du jour de la planification
Supportez ces objectifs en définissant comment va se dérouler chaque session de planification.
J’encourage mes équipes à utiliser un ordre du jour standard pour tous les événements de planification.
Utilisez cet ordre du jour type pour encourager votre équipe à faire de même :
Examiner les résultats de notre session de brainstorming préparatoire.
Appliquer les critères de priorisation pour créer une liste agréée de travail pour ce sprint
Définir ensemble qui va construire et qui va tester le résultat.
Chaque personne crée son propre échéancier pour le sprint en s’assurant que les must have ne dépasse pas les 60 % du travail.
Chacun effectue un contrôle croisé de son échéancier avec la personne testant son travail.
Réserver le temps nécessaire dans son agenda pour réaliser le travail
Se mettre d’accord sur comment vous partagerez le progrès avec l’autre
Matchware est partenaire de DantotsuPM
Pour plus d’astuces sur l’application des pratiques de travail Agile dans la vraie vie, abonnez-vous au bulletin de Melanie ou visitez son site Web.
partagez ce billet avec vos amis, collègues et relations professionnelles
Comme l’ère du carburant fossile approche de sa fin, les pompistes (le peu qu’il en reste, ainsi que les pompistes bénévoles qui remplissent eux-mêmes leurs propres réservoirs) persistent à vouloir remplir le réservoir à ras bord.
Après que le déclencheur automatique ait détecté que le réservoir est plein, ils ajoutent dix ou vingt centimes de plus de carburant pour atteindre un chiffre rond.
Pourquoi ?
Ce n’est pas plus rapide. Cela demande du temps pour le faire manuellement.
Ce n’est pas plus profitable. Dix centimes supplémentaires sur un réservoir de 60€ ne justifient pas le temps.
Ce n’est pas plus efficace. Le nombre de kilomètres de plus d’ici au prochain plein est minuscule.
Ce n’est même pas plus facile. La plupart des personnes paient avec une carte de crédit, donc l’arrondi n’aide en rien.
Et…
Cela risque plus probablement d’endommager le véhicule (l’essence sur la carrosserie) et d’endommager la santé du pompiste (avec les vapeurs).
Alors, pourquoi le font-ils ?
Trois raisons
Tradition.
Montrer au chef et au client que vous bossez dur.
Une apparence de contrôle.
Trop déléguer nous fait ressembler à des automates.
C’est la troisième qui est la vraie. Les gens échangent d’énormes quantités de décisions en échange de convenance personnelle, mais pas trop de décisions.
Trop déléguer nous fait ressembler à des automates. Même (ou particulièrement) en travaillant sur des automobiles qui sont des symboles de liberté et de contrôle.
Quelles autres choses cherchons-nous à remplir à ras bord ?
Dans le monde du management de projet, n’en va-t-il pas de même ?
N’essayons-nous pas trop souvent de surcharger le contenu de nos livrables de bien plus de fonctionnalités qu’il n’est raisonnable d’en embarquer ?
Ce n’est pas plus rapide. Cela demande plus de temps pour produire la version de notre livrable qui réponde à tous ces besoins dont certains sont probablement moins critiques que d’autres.
Ce n’est pas plus profitable. Comme nous le constatons avec les méthodes Agiles de type Scrum, il vaut mieux limiter le contenu à la durée et à la capacité de production pour obtenir rapidement un produit qui apporte déjà des bénéfices.
Ce n’est pas plus efficace. Produire et tester un livrable beaucoup plus complexe coûte plus de temps et de moyens que plusieurs plus simples.
Ce n’est même pas plus facile. Le suivi des développements et des tests, ou la formation des futurs utilisateurs sont bien plus compliqués.
Et…
Cela risque plus probablement d’endommager le produit (le surplus de fonctionnalités pas toujours critiques ralentit l’adoption par les utilisateurs et accroit les risques de dérapage des délais) et d’endommager la santé des membres de l’équipe projet (en surchargeant leurs plannings et leur mental de choses non critiques).
CertYou est partenaire de DantotsuPM
Alors, pourquoi le faisons-nous encore très fréquemment ?
partagez ce billet avec vos amis, collègues et relations professionnelles
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 
Suivez soigneusement comment les tâches sont décomposées et assignées et si vous remarquez qu’il y a un déséquilibre, dites-le. Chacun devrait se voir assigné autant de travail qu’il peut en achever et des tâches pour lesquelles il est qualifié. Communiquez régulièrement avec votre équipe pour vous assurer que personne n’est surchargé, sous-chargé, ou a été assigné du travail hors de portée de ses capacités. La répartition appropriée du travail est cruciale pour établir un système de management de productivité efficace.
DantotsuPM.com 