Rencontres sur le management de projets – 15 au 21 Octobre

2 very different topics for PMs this week: Decommissioning projects in Switzerland and Agile tour in London.

Jeudi 18

James Greene is a founding member and former President of the PMI Switzerland Chapter.

« While most project managers are familiar with implementation projects, the decommissioning of business applications, manufacturing systems or business processes are usually not given the same kind of attention. However, decommissioning projects are almost always much more complex and challenging projects to lead ! » James Greene

Méta Projets Management est partenaire de DantotsuPM

Vendredi 19

Agile Tour London is a conference about Agile in its general approach, where agilists of all background can meet to exchange ideas, refresh their minds, evaluate issues and renew their own approach to Execute Everyday Agile.

CertYou est partenaire de DantotsuPM

 

Importance de la co-localisation dans la collaboration

Avec Agile, une communication large-bande est nécessaire !

Importance of Colocation in Collaboration

https://www.scrumstudy.com/blog/importance-of-co-localisation-in-collaboration/  par SCRUMstudy

Pour beaucoup des aspects pratiques de Scrum, la communication large-bande est exigée.

Pour le permettre, il est préférable que les membres d’équipe soient localisés géographiquement au même emplacement. La co-localisation permet des interactions tant formelles qu’informelles entre les membres de l’équipe. Cela fournit l’avantage d’avoir les membres d’équipe toujours à portée de main (et de voix) pour la coordination, la résolution de problèmes et pour apprendre.

Certains des bénéfices de la co-localisation

  • Les questions trouvent rapidement des réponses.
  • Les problèmes sont fixés dans l’instant et sur place.
  • Moins de friction entre les interactions.
  • La confiance est gagnée et allouée beaucoup plus rapidement.
CertYou est partenaire de DantotsuPM

Des outils de collaboration peuvent être utilisés pour les équipes co-localisées ou distribuées

1. Équipes co-localisées (c’est-à-dire, équipes travaillant dans le même bureau)

Avec Scrum, il est préférable d’avoir des équipes co-localisées. Si co-localisées, les modes préférés de communication incluent des interactions en face à face, des salles partagées ou War Rooms, des tableaux Scrum, des affichages muraux, des tables partagées, etc.

2. Équipes distribuées (c’est-à-dire, équipes travaillant dans emplacements géographiques/physiques différents)

Bien que des équipes co-localisées soient préférables, de temps en temps l’équipe Scrum peut devoir être distribuée pour des raisons d’externalisation, d’offshoring, de sites géographiques multiples, d’options de travail-à-la-maison, etc. Certains outils à utiliser pour une collaboration efficace avec des équipes distribuées incluent la communication par vidéo, la messagerie instantanée, les outils de chats, les médias sociaux, les écrans partagés et les outils logiciels qui digitalisent la fonctionnalité des tableaux Scrum, murs partagés, et cetera.

Coûts supplémentaires à prévoir impérativement

Si la co-localisation n’est pas possible et qu’il y a des équipes distribuées,des ressources complémentaires devront être consacrées à faciliter des communications.

Ainsi qu’à comprendre les différences culturelles, synchroniser le travail et favoriser le partage de connaissance.

Juillet 2018 fut l’occasion de revenir sur quelques fondamentaux dans nos vies de chefs de projet (et en dehors)

Ikigai, Cynefin, Manifeste Agile, confiance et devenir un bon mentor de projet, tels étaient les sujets qui vous intéressèrent le plus en Juillet.

l’ Ikigai est la raison de vous lever le matin

Chacun a un Ikigai, c’est notre moteur intrinsèque. Vous devez le chercher et l’identifier pour découvrir votre source personnelle de valeur dans votre vie ou les choses qui rendent votre vie digne d’être vécue. La découverte de son Ikigai apporte le sens, le bonheur et la satisfaction.

vous êtes chef de projet, ce n’est pas sans raison ! Ayez confiance en vos capacités.

CertYou est partenaire de DantotsuPM

Le Manifeste Agile, ses 4 valeurs et 12 principes, par QRP International

Le Manifeste Agile, ses 4 valeurs et 12 principes, sont la conséquence de la frustration des entreprises dans les années 1990 sur le laps de temps entre l’expression des besoins de l’entreprise et la livraison technologique de la solution. Les besoins business et métier évoluent pendant cette période et le produit final ne répond jamais aux besoins du moment qui ont changé.

QRP International est Partenaire de DantotsuPM

une approche pour comprendre et appréhender la complexité grâce au modèle Cynefin

Cynefin parle de quatre types différents de problèmes ou domaines. Évident, Compliqué, Complexe et Chaotique. Nous aborderons ces premiers et couvrirons à la fin le Désordre.

Comment être ou devenir un bon mentor de Chef de Projet en 6 étapes ?

Les débutants qui prennent leur premier job de management de projet ont besoin de quelqu’un pour les guider et les aider à passer l’environnement agité, cependant productif de ces tâches : un mentor.

Si vous êtes déjà un mentor de chef de projet, vous êtes déjà familiers avec cette situation; vous décelez les erreurs des débutants et êtes un peu frustré lorsqu’ils s’avèrent incapables d’accomplir le travail que l’on attend d’eux. Alors, vous appliquez les méthodes nécessaires pour les aider à sortir de leur tracas et à évoluer par eux-mêmes.

Si vous n’êtes pas encore un mentor de projet, mais voulez le devenir, voici quelques étapes pour vous assurer que votre protégé recevra autant de formation qu’il ou elle lui en faut pour survivre dans le management de projet.

Méta Projets Management est partenaire de DantotsuPM

SCRUM ne s’applique pas seulement dans le développement de logiciels, bien au contraire

Scrum est une méthode universelle

Il y a quelques années, Craig Brown qui anime le Melbourne Scrum User group a commencé à prôner que Scrum est une méthode universelle et non pas réservée uniquement aux projets de développement de logiciels.

Voici ce que je retiens encore aujourd’hui de la description qu’il donnait de Scrum et qui s’applique à tout projet :

1. Commencez avec un objectif. Puis, décomposez-le en étapes incrémentales.

2. Discutez des étapes avec l’équipe qui doit livrer la solution.

3. Définissez des périodes de temps standards (timebox) pour les itérations. Faites de votre mieux pour livrer quelque chose de valeur, utilisable et utile à chaque itération.

4. L’équipe prend ses « ordres » (ses priorités) du client au début de chaque itération et fait un rapport sur ce qui a été « fait » (totalement achevé) à la fin de chaque itération (Sprint Review).

5. L’équipe doit mettre du temps de coté au début de chaque itération pour planifier son travail (Sprint Planning).

6. L’équipe doit aussi mettre du temps de coté pour une brève session d’échanges chaque jour entre ses membres sur les progrès réalisés et les problèmes rencontrés (Daily Scrum).

7. L’équipe doit s’engager à l’amélioration continue et mettre du temps de coté à chaque itération pour réfléchir à ce qui est bien allé ou pas et identifier où l’on peut s’améliorer et comment (Sprint Retrospective).

8. La planification, la revue et les sessions de réflexion et réunions d’équipe quotidiennes doivent avoir lieu à des heures régulières pour aider l’équipe à trouver et tenir un rythme.

CertYou est partenaire de DantotsuPM

plusieurs astuces utiles pour les chefs de projet dans les articles les plus lus sur le blog DantotsuPM en Juin 2018

Cette “Règle 1-3-5” peut complètement changer votre To-Do Liste !!!

Essayez-vous de tout accomplir, seulement en vous consommant et finissant par vous sentir toujours plus en retard ?

S’il en est ainsi, vous n’êtes pas tout seul.

J’ai personnellement essayer cette technique et elle marche mais demande énormément de rigueur et d’attention. Les premiers temps, mes estimations de durée entre les choses grandes, moyennes et plus petites, étaient erronées et bien sûr il est souvent difficile d’avancer comme on le voudrait sur sa to-to Liste à cause des impondérables opérationnels de la vraie vie au travail.

Que faire quand une personne s’accapare la discussion ?

 

Comment le manager ou le chef de projet devrait-il gérer un dominateur pendant une réunion d’équipe ?

Le Problème : Chacun a eu l’occasion de rencontrer “LE dominateur” (ou LA dominatrice).

C’est la personne dans le groupe qui semble s’approprier la discussion et ne plus laisser d’autres personnes s’exprimer. Parfois ce sont seulement des bavards trop prolifiques… …d’autres fois, ce sont des personnalités excessivement agressives qui pompent tout l’oxygène de la pièce.

3 pratiques Agiles faciles que votre équipe peut commencer dès aujourd’hui

Vous avez entendu vos amis chanter les louanges d’Agile. Vos copains chefs de projet deviennent des scrum masters. Vous entendez combien c’est formidable. Tous les gamins dans le coup le font et vous êtes un peu jaloux. Vous vous sentez exclu. Vous voulez voir l’objet de toute cette agitation.

Bonnes nouvelles ! Il existe des pratiques Agiles que vous pouvez utiliser même dans votre monde prédictif en cascade. Vous obtiendrez les bénéfices d’une communication accrue, de la collaboration avec le client et de l’amélioration continue. Et vous aurez une opportunité de présenter quelques pratiques Agiles à votre équipe. Sans devoir vous coller à la transition de l’organisation toute entière vers Agile.

CertYou est partenaire de DantotsuPM

Que signifie vraiment “le Produit Viable Minimal” ou mVP de toute façon ?

Un processus MVP simplifié en 3 étapes

  1. Source : Egg Lighting

    Commencez avec un produit simple et unique résolvant un minuscule sous-ensemble d’un grand problème;

  2. Continuez à itérez, en résolvant constamment de plus grands problèmes connectés à la résolution du grand problème;
  3. Communiquez constamment la vision du grand problème qui sera résolu.

10 bénéfices à connaître sur le Management Portefeuille de Projet

Dans ce billet sont listés Dix Bénéfices du Management de Portefeuille de Projet qui aideront votre projet à recevoir l’attention qu’il mérite. Ces bénéfices sont aussi accompagnés par le Bureau de Management de Projets (Project Management Office / PMO) pour améliorer votre taux de succès dans les projets.

SMPP est Partenaire de DantotsuPM

Mai 2018 – articles les plus lus par les lecteurs du blog DantotsuPM

Management de projet hybride, nouveaux guides du PMI, outils Microsoft… mais aussi se comporter en adulte furent les billet qui retinrent votre attention en Mai 2018 et que vous aimerez peut-être relire ou découvrir en cette période estivale plus calme.

« une main de fer dans un gant de velours » avec les approches prédictives et Agile selon Christine Rieu, Sylvain Gautier et Marc Burlereaux

Cet article publié il y a plusieurs années et repris à l’occasion du forum des régions PMI France 2018 a connu un regain de succès. C’est très mérité car les auteurs, Christine Rieu, Sylvain Gautier et Marc Burlereaux, avaient pris le temps de partager avec nous leur expérience de l’agilité et premières idées pour adopter une approche plus hybride.

L’approche Agile dans les projets de développement de nouveaux produits permet d’assurer plus de souplesse dans la conception itérative, plus de légèreté dans la documentation et dans la formalisation, plus d’interactivité  et d’efficacité dans la conduite de réunions, et surtout plus d’implication du client tout au long du projet. En couplant une approche Lean à ces méthodes Agiles, nous supprimons en plus  toutes les étapes inutiles sans valeur ajoutée pour limiter les gaspillages et maximiser ainsi la valeur attendue du produit.

Une liste de 25 principes de comportement adulte par John Perry Barlow

Quand il avait 30 ans, le fondateur de l’Electronic Frontier Foundation (et parfois parolier de Grateful Dead) a rédigé une liste de ce qu’il a appelé « les Principes de Comportement Adulte ». Lesquels 5 ou 6 éliriez-vous dans cette liste pour votre propre éthique ? J’aime beaucoup 2,3,4,5,6,7,8…

…impossible de choisir.

Microsoft Planner ou Microsoft Project: Lequel utiliser pour manager vos projets ?

À ce jour, vous êtes probablement déjà familiers de Microsoft Project. Sorti en 1990, Microsoft Project est devenu l’application par défaut pour les chefs de projets. Microsoft Planner est une solution de gestion de projet plus récente qui a été publiée en 2016 dans le cadre d’Office 365. Les deux applications nous laissent créer des plans, organiser et confier des tâches, partager des dossiers, communiquer avec des collègues et obtenir des mises à jour sur le progrès de notre équipe.
Alors, quelle solution devrions-nous utiliser ?le combiné « Guide PMBOK® + Guide pratique des méthodes Agiles » du Project Management Institute est disponible en français
Afin de soutenir l’éventail de plus en plus large des approches de réalisation de projets, PMI propose un PMBOK® Guide – Sixième édition accompagné du nouveau Guide de pratiques Agiles.

Gratuits pour les membres du PMI

En mode ‘Ciel, mon outil PPM !’, 6 points-clé à ne pas manquer pour réussir le choix de sa solution de pilotage des projets !

Quand le sujet de choisir son outil PPM devient un vrai casse-tête, que vous vous perdez devant la pléthore d’offres et que vous ne savez plus vraiment comment faire le bon choix…

Pas de panique, détendez-vous ! On vous dit tout !

SMPP est Partenaire de DantotsuPM

quels billets les suiveurs du blog DantotsuPM ont-ils le plus aimés en Mars 2018 ?

Outils, méthodes, retour d’expérience, PMO… ces sujets variés du mois de Mars 2018 ont retenu votre attention.

une check-list simple et concrète pour vérifier si nous faisons vraiment du Scrum ou nous y préparer et améliorer

Voici une check-list fort utile et déjà très utilisée qui est traduite en de nombreuses langues dont le français !

qu’utilisez-vous pour documenter les Rôles et Responsabilités ?

RACI-exemple PMGSLa RAM, Responsibility Assignment Matrix, ou Matrice d’Affectation des Responsabilités sert à documenter les rôles et responsabilités de chacun dans le projet.

Cet outil, qui prend la forme d’un tableau (qui croise la structure de décomposition du projet/WBS et les ressources de l’organisation) permet au chef de projet de lister les participants au projet ainsi que leur(s) responsabilité(s).

Le RACI  est l’exemple de RAM le plus utilisé, a pour point de départ le croisement de la structure de découpage de projet ou SDP/WBS avec les ressources du projet.

Est-ce un projet ou une activité régulière ? Comment faites-vous la différence entre les 2 ?

« Qu’est-ce qui différencie les projets des activités régulières ? »: Lors de votre prochain entretien pour un job de chef de projet, cette question pourrait fort bien vous être posée.

Alors, que répondre ? ==> 3 éléments majeurs

voici les principes de base d’un chercheur en physique, ils s’appliquent fort bien au management de projets

Une lettre d’un chercheur en physique au Laboratoire Lawrence Livermore du nom de Tom Hirshfield. Tom y partageait quelques principes de base qu’il avait personnellement trouvés utile dans son travail et à utiliser comme bon vous semble dans le votre.

Selon vous, quelles sont les étapes majeures pour mettre en place notre PMO ?

Voici quelques-unes des étapes sur lesquelles je plancherais pour préparer un plan à 90 jours que je pourrais proposer à mon futur employeur dès les premiers entretiens…

Qu’est-ce que le “Scrum of Scrums” ?

What is Scrum of Scrums?

https://www.scrumstudy.com/blog/what-is-scrum-of-scrums/ par SCRUMstudy

Qu’est-ce que le Scrum of Scrums et comment fonctionne-t-il dans le processus de développement de produit ?

La première chose à savoir sur le Scrum of Scrums est qu’il devient pertinent seulement pour de grands projets où de multiples équipes Scrum sont impliquées. Dans ce processus, les représentants d’équipes Scrum se rassemblent pour la réunion Scrum of Scrums à intervalles de temps prédéterminés ou chaque fois qu’il est nécessaire de collaborer et suivre leurs progrès, obstacles et dépendances respectifs à travers les multiples équipes Scrum.

Qui participe ?

Normalement, un membre de chaque équipe Scrum représentera son équipe dans la réunion Scrum of Scrums. Dans la plupart des cas, c’est le Scrum Master, mais de temps en temps quelqu’un d’autre peut représenter l’équipe. Une unique personne peut être nommée par l’équipe pour la représenter à chaque réunion Scrum of Scrums, ou bien le représentant peut changer au fil du temps, en fonction de qui peut remplir au mieux le rôle en raison des questions et circonstances actuelles. Chaque participant à la réunion devrait avoir la compréhension technique et être capable d’identifier des situations dans lesquelles les équipes pourraient causer obstacles ou retards les unes aux autres.

D’autres participants importants de réunion Scrum of Scrums incluent Scrum Master en chef et le Propriétaire de Produit en chef. Le but principal de la réunion Scrum of Scrums est de communiquer sur la progression entre des équipes multiples. Le Scrum Master en chef (ou n’importe quel Scrum Master qui faciliterait la réunion Scrum of Scrums), peut proposer un ordre du jour avant la réunion. Cela permet à chaque équipe de considérer les sujets de l’ordre du jour en préparant la réunion Scrum of Scrums.

De quoi discute-t-on ?

Tous les obstacles rencontrés par une équipe et qui peuvent aussi affecter d’autres équipes, devraient être remontés ainsi ils peuvent être discutés. De plus, si une équipe prend conscience d’un gros problème, changement ou risque qui peut impacter d’autres équipes, il devrait être communiqué lors de la réunion Scrum of Scrums.

Book on Amazon

Les productions des rétrospectives de Sprint peuvent aussi élever des problèmes qui pourraient impacter de multiples équipes Scrum et pourraient être utilisées lors de la réunion Scrum of Scrums. Ces réunions sont de préférence brèves (mais d’habitude non limitées dans le temps pour favoriser davantage d’échanges d’information entre les équipes) auxquelles se joint un représentant de chaque équipe Scrum pour partager le statut de son équipe. La réunion Scrum of Scrums  se tient à intervalles prédéterminés ou quand demandé par des équipes Scrum. Ces réunions facilitent le partage en face-à-face d’informations entre des équipes Scrum différentes des difficultés, des dépendances et des risques qui doivent être étroitement contrôlés. Ceci aide les diverses équipes travaillant sur un grand projet à mieux coordonner et intégrer leur travail. C’est la responsabilité du Scrum Master en chef (ou tout autre Scrum Master qui facilite la réunion Scrum of Scrums) de s’assurer que tous les représentants ont un environnement contribuant à partager ouvertement et honnêtement l’information, y compris les réactions des représentants d’autres équipes. Pour de plus grands projets, impliquant un nombre significatif d’équipes, de multiples niveaux de ces réunions peuvent être implémentés. Chaque représentant d’équipe Scrum fournira à son tour les avancées de son équipe.

On donne d’habitude ces éléments en répondant à quatre questions spécifiques.
  1. Sur quoi mon équipe a-t-elle travaillé depuis la dernière réunion ?
  2. Que mon équipe fera-t-elle d’ici la prochaine réunion?
  3. Quel reste-t-il à faire à mon équipe pour répondre aux attentes d’autres équipes ?
  4. Que mon équipe va-t-elle faire qui pourrait impacter d’autres équipes ?

Les réponses à ces quatre questions fournissent l’information qui permet à chaque équipe de comprendre clairement le statut du travail de toutes les autres équipes. On recommande qu’une salle de réunion dédiée soit rendue disponible pour la réunion Scrum of Scrums, où tous les représentants d’équipes Scrum sont à l’aise.

Pour quels bénéfices ?

Dans le processus Scrum of Scrums, les meilleures pratiques pourraient être documentées sur la façon de conduire la réunion Scrum of Scrums et des suggestions incorporées dans le travail de projet d’équipes Scrum individuelles.

Il peut aussi y avoir une équipe d’experts du sujet qui peuvent aider le Scrum Master en chef à faciliter la réunion Scrum of Scrums.

L’une des productions importantes de la réunion Scrum of Scrums est la coordination du travail à travers des équipes Scrum multiples. C’est particulièrement important quand il y a des tâches avec des dépendances inter-équipes. Les incompatibilités et contradictions entre le travail et les livrables d’équipes différentes sont rapidement exposées.

Ce forum donne aussi aux équipes l’occasion de présenter leurs accomplissements et donner des retours à d’autres équipes.

En utilisant la réunion Scrum of Scrums, il y a de la collaboration à travers toute l’organisation par opposition à des personnes travaillant dans des équipes renfermées et concernées principalement par leurs responsabilités individuelles. La réunion Scrum of Scrums est un forum où les membres d’équipe Scrum ont l’occasion de discuter des problèmes impactant leur projet d’une manière transparente.

Le besoin de livrer chaque Sprint à l’heure force les équipes à confronter activement de telles questions au lieu de reporter à plus tard la recherche de résolution. Cette discussion et résolution opportunes de questions dans la réunion Scrum of Scrums améliorent énormément la coordination entre des équipes Scrum différentes et réduit aussi le besoin de refaire et retravailler. Les risques liés aux dépendances et délais de livraison sont aussi atténués.

CertYou est partenaire de DantotsuPM

Quelles sont les alternatives au Agile Planning Poker de Scrum ?

Alternatives to Planning Poker

https://www.extremeuncertainty.com/alternatives-planning-poker/ de leontranter

Le Planning Poker est une façon commune de réaliser l’estimation des points d’histoire utilisateur. Il présente quelques avantages, mais aussi quelques problèmes.

 

 

 

 

 

Qu’est-ce que ce Planning Poker ?

Le Planning Poker est souvent utilisé dans des équipes Scrum (bien qu’il ne soit mentionné nulle part dans le guide Scrum selon la croyance populaire). Mike Cohn l’a popularisé dans son livre “Agile Estimating and Planning“. C’est une technique d’équipe pour collectivement estimer les points d’histoires d’utilisateur. (Pas sûr de ce que cela signifie ? Lisez le « guide to story point estimation »).

Si vous êtes déjà familiers du Planning Poker, n’hésitez pas à sauter directement plus bas “la planification d’alternatives au Planning Poker”. Sinon, continuez de lire pour une explication de comment cela fonctionne et pourquoi les gens l’utilisent.

CertYou est partenaire de DantotsuPM

Comment fonctionne-t-il ?

Disons que vous avez une équipe de sept ou huit personnes, qui ont environ une douzaine d’histoires d’utilisateur dans leur arriéré de produit qu’ils voudraient estimer. Pour le faire via le Planning Poker, chaque personne dans l’équipe aura une certaine méthode pour fournir un chiffre. C’est d’habitude via un sabot de cartes de poker, mais vous pourriez aussi utiliser une app sur votre téléphone. Les chiffres sont d’habitude des nombres de la suite de Fibonacci, une série où chaque nombre est la somme des deux nombres précédents. Donc cela donne 1, 2, 3, 5, 8, 13, 21, et cetera (on ne va d’habitude pas dépasser 21 parce que les histoires d’utilisateur ne devraient jamais être beaucoup plus grandes que d’autres).

L’équipe prend la première histoire de la liste et en discute un moment. Souvenez-vous, une histoire d’utilisateur est écrite comme une déclaration de problème. L’équipe réfléchit ensuite à combien de travail il faudrait pour répondre à cette déclaration de problème, c’est-à-dire mettre en œuvre une solution qui réalise le comportement décrit dans l’histoire.

Estimation de Planning Poker

Une fois que l’équipe est prête à estimer, chaque personne choisit un numéro de son jeu de cartes. Ils le font en silence. Puis, chaque personne révèle son évaluation en même temps.

La raison de procéder ainsi est que l’évaluation d’une personne ne devrait pas influencer l’évaluation d’une autre. Si chaque personne fournit son évaluation à son tour, la première personne pourrait choisir une grande (ou petite) estimation, qui pourrait faire changer d’avis d’autres personnes et ainsi biaiser leur évaluation. Le processus est destiné à permettre à chaque personne de fournir sa propre évaluation impartiale et honnête.

Bien sûr, les valeurs sont souvent différentes, ce qui signifie qu’une autre discussion démarre. Il y a parfois alors un autre round d’évaluation. Quelques puristes de Scrum insistent pour que l’équipe continue les rounds d’évaluation jusqu’à ce que chacun arrive au même nombre. Je pense que c’est de la folie et que cela encourage ce que le planning poker devrait empêcher : les gens « forçant » d’autres à être d’accord avec leur évaluation.

Je pense que cela devrait continuer jusqu’à ce qu’un consensus soit atteint, ce qui est d’habitude très clair (et PAS la même chose que la conformité, c’est-à-dire quand chacun a la même valeur). S’il y a une gamme d’évaluations consistant de 2, 2, 3, 3, 5, 5, l’estimation est de 3. Cela ne doit pas être une moyenne exacte, mais une médiane suffit. Et cela ne doit pas être mathématiquement précis. Les évaluations sont essentiellement des suppositions informées. Le processus d’évaluation n’est pas précis donc les évaluations ne le seront jamais et c’est ok.

Alors, pourquoi chercher des alternatives au Planning Poker?

Vous pourriez vous demander pourquoi vous voudriez des alternatives à le Planning Poker. Ce n’est pas un mauvais système, mais il a quelques problèmes.

Il est lent

Cela peut prendre une longue période de temps pour faire l’évaluation avec le Planning Poker. J’ai vu des sessions de deux ou trois heures et ce n’est pas amusant. Montrer ces cartes est au départ amusant mais cela devient usant vraiment rapidement. Tergiverser sur savoir si quelque chose vaut 2 ou 3 est ennuyeux et irritant et ce n’est pas une conversation de valeur.

Il distrait

La discussion sur quelle carte est bonne ou fausse peut distraire les gens d’une conversation de plus de valeur : la discussion de la solution. Particulièrement, pourquoi quelqu’un estime que quelque chose mérite 2 ou 3 par opposition à une autre valeur.

Il peut donner une fausse impression des estimations

Certaines personnes pensent que si vous faites ce jeu intelligemment, alors les évaluations elles-mêmes deviennent soudainement plus précises et donc de plus de valeur. C’est complètement faux. Le Planning Poker est une bonne façon d’atteindre un consensus sur des évaluations. Cela ne signifie pas qu’elles soient précises. Il est très possible pour un groupe de personnes d’être dans l’erreur à propos de quelque chose (particulièrement quelque chose de notoirement difficile à évaluer comme la complexité de développement de logiciel).

Les alternatives au Planning Poker

Il y a quelques alternatives que vous pouvez essayer si vous vous fatiguez du Planning Poker, ou pensez que cela pourrait être mieux.

Classement par taille de t-shirt

Au lieu des nombres (Fibonacci ou autres, vous pouvez utiliser des tailles de T-shirt. Petit, moyen, large, extra-large. Cela vous donne une plus petite gamme d’estimations possibles, ce qui signifie que vous obtiendrez moins de désaccords et moins de variance. Vous pourriez penser que les évaluations seront moins précises, mais je ne pense pas qu’elles le seront. Je constate que les tailles de t-shirt sont suffisantes. Vous aurez besoin de quelques références pour ces tailles; utilisez simplement des histoires ou des fonctions précédentes. (J’aime en réalité faire des évaluations de taille de t-shirt et aucune autre estimation  d’histoire). Vous pourriez aussi utiliser un jeu plus réduit de nombres (1, 5, 8, 20) ou autre chose pour remplacer les tailles de t-shirt. Mais j’aime le fait que des nombres ne soient pas utilisés. Cela clarifie le fait que ce ne sont pas des mesures et elles ne sont pas précises.

Pour l’estimation précise, vous pouvez utiliser la technique du planning poker, ou la Technique « Affinity Mapping ».

Affinity Mapping

Vous pourriez être familiers avec la technique « Affinity Mapping » car elle est utilisée dans les Rétrospectives de Sprint. C’est une technique pour grouper ensemble des articles semblables. Commencez par créer une série d' »étiquettes » ou de « piles » sur la table : celles-ci pourraient être numérotés selon Fibonacci, ou les tailles de t-shirt, ou des catégories, ou quoi que ce soit. Puis, vous déposez les histoires sur la table comme des cartes. Ensuite, l’équipe déplace collectivement les cartes dans les piles pour les représenter selon leur estimation.

Petite Vidéo de Vincent Drecq, auteur du livre en français « Pratiques de management de projets ». 

 

 

 

Classement silencieux par taille

C’est une technique intéressante, peu commune et peu connue. C’est une manière efficace d’évaluer un grand nombre d’histoires dans un espace de temps très court. Commencez par définir vos points de référence (nombres de Fibonacci, tailles de t-shirt, etc). Créez des piles sur la table selon la technique « Affinity Mapping ». Ensuite, chaque personne est aléatoirement assignée un jeu d’histoires à estimer (peut-être en distribuant les histoires comme si elles étaient des cartes à jouer). Puis, à tour de rôle, chaque personne évalue en silence en plaçant une carte sur une des piles. Alternativement, une personne peut déplacer une carte d’une pile à une autre, si elle est convaincue qu’une estimation est incorrecte.

Continuez à faire ceci jusqu’à ce que toutes les cartes soient estimées. Si une carte est déplacée deux fois, ôtez-la de la table – elle aura besoin d’une discussion séparée après la réunion car il y a un fort désaccord sur son estimation.

L’avantage de cette technique est qu’une équipe peut évaluer beaucoup d’histoires en un très court laps de temps. A utiliser si l’on vous demande d’évaluer 100 histoires (même si je pense que c’est le signe d’un plus gros problème car vous devriez seulement évaluer un ou deux sprints d’histoires Utilisateurs à l’avance). L’inconvénient est que vous sautez ce qui est souvent la partie de plus de valeur : la discussion autour des histoires.

Aucune évaluation

D’autres personnes prennent une position plus extrême. Ils pensent que nous devrions nous débarrasser totalement des estimations ! C’est un mouvement qui est souvent identifié par le  hashtag Twitter #NoEstimates. Il a été lancé il y a quelques années par quelqu’un appelé Woody Zuil et est principalement soutenu par un coach Agile nommé Vasco Duarte. Si vous voulez l’essayer, c’est facile : n’abandonnez pas seulement le Planning Poker, abandonnez aussi toute estimation. Vous pouvez alors faire deux ou trois choses :

  • Donnez une évaluation moyenne sur toutes les histoires (utilisez une moyenne historique, total ou roulant la moyenne des trois derniers sprints)
  • Oubliez les points d’histoire et utilisez juste le nombre d’histoires pour la planification
  • Oubliez le planning d’histoires et estimez par fonctionnalité, utilisant probablement des tailles de t-shirt / le nombre de sprints.

En ce qui me concerne, je tombe dans le dernier camp. Je ne pense pas que les évaluations d’histoire sont très forte valeur, bien que des évaluations de haut niveau de fonctionnalités soient utiles pour la planification de release (et j’ai constaté qu’elles sont souvent aussi ou plus précises qu’une somme d’évaluations de point d’histoire).

 

#NoEstimates est un sujet complexe et très controversé et qui mérite une discussion séparée.

Conclusion

Vous pouvez essayer ces techniques et voir ce qu’en pense l’équipe. Assurez-vous de les considérer comme des expériences et recueillez-en les données: L’équipe estime-t-elle que c’est mieux que le planning poker ? Les évaluations se sont-elles avérées de plus de valeur ?

Rappelez-vous que la chose qui a le plus de valeur dans une session d’estimation est d’habitude les conversations autour de la solution, pas les nombres estimés.

Différences entre diverses langues dans l’expression d’un principe #Agile par Ian Raja Stokes

Voyons la différence en diverses langues dans l’expression du principe 4 parmi les 12 principes associés au manifeste agile !

« Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet »

Que je traduis en Anglais à titre de comparaison : “Business people and developers must work together daily throughout the project”

  • Français: « users or their representatives and developers »
  • Allemand: « specialists and developers »
  • Italien: « clients and developers »
  • Anglais: « business people and developers »
  • Espagnol: « business managers and developers »
  • Néerlandais: « business people and developers »
  • Suédois: « business people and developers »
  • Finlandais: « business representatives and software developers »
  • Turc: « owners of business processes and software »
  • Croate: “business people and development engineers”
  • Polonais: « business and development teams »
  • Russe: « developers and business »
  • Chinois: « business people and developers »
  • Japonais: « business people and developers »

Selon vous, ces différences sont-elles significatives dans la manière d’aborder l’agilité ?

Par rapport à mon expérience personnelle, je crois que la réponse est « oui ».

Relisez le billet de notre partenaire QRP International

Nous avons ainsi des versions différentes de l’agilité en fonction de la langue utilisée.